On 7/12/18 1:04 AM, Michal Hocko wrote:
On Wed 11-07-18 10:04:48, Yang Shi wrote:
[...]
One approach is to save all the vmas on a separate list, then zap_page_range
does unmap with this list.
Just detached unmapped vma chain from mm. You can keep the existing
vm_next chain and reuse it.
Ye
On Wed 11-07-18 15:49:54, Andrew Morton wrote:
> On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko wrote:
>
> > > Approach:
> > > Zapping pages is the most time consuming part, according to the
> > > suggestion from
> > > Michal Hocko [1], zapping pages can be done with holding read mmap_sem,
> >
On Wed 11-07-18 10:04:48, Yang Shi wrote:
[...]
> One approach is to save all the vmas on a separate list, then zap_page_range
> does unmap with this list.
Just detached unmapped vma chain from mm. You can keep the existing
vm_next chain and reuse it.
--
Michal Hocko
SUSE Labs
On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko wrote:
> > Approach:
> > Zapping pages is the most time consuming part, according to the suggestion
> > from
> > Michal Hocko [1], zapping pages can be done with holding read mmap_sem, like
> > what MADV_DONTNEED does. Then re-acquire write mmap_se
On 7/11/18 4:53 AM, Michal Hocko wrote:
On Wed 11-07-18 14:13:12, Kirill A. Shutemov wrote:
On Wed, Jul 11, 2018 at 12:33:12PM +0200, Michal Hocko wrote:
this is not a small change for something that could be achieved
from the userspace trivially (just call madvise before munmap - library
ca
On 7/11/18 4:10 AM, Kirill A. Shutemov wrote:
On Wed, Jul 11, 2018 at 07:34:06AM +0800, Yang Shi wrote:
Background:
Recently, when we ran some vm scalability tests on machines with large memory,
we ran into a couple of mmap_sem scalability issues when unmapping large memory
space, please refe
On 7/11/18 3:33 AM, Michal Hocko wrote:
On Wed 11-07-18 07:34:06, Yang Shi wrote:
Background:
Recently, when we ran some vm scalability tests on machines with large memory,
we ran into a couple of mmap_sem scalability issues when unmapping large memory
space, please refer to https://lkml.org/
On Wed 11-07-18 14:10:52, Kirill A. Shutemov wrote:
[...]
> It's okay. I have another suggestion that also doesn't require VM_DEAD
> trick too :)
>
> 1. Take mmap_sem for write;
> 2. Adjust VMA layout (split/remove). After the step all memory we try to
>unmap is outside any VMA.
> 3. Downgrade
On Wed 11-07-18 14:13:12, Kirill A. Shutemov wrote:
> On Wed, Jul 11, 2018 at 12:33:12PM +0200, Michal Hocko wrote:
> > this is not a small change for something that could be achieved
> > from the userspace trivially (just call madvise before munmap - library
> > can hide this). Most workloads will
On Wed, Jul 11, 2018 at 12:33:12PM +0200, Michal Hocko wrote:
> this is not a small change for something that could be achieved
> from the userspace trivially (just call madvise before munmap - library
> can hide this). Most workloads will even not care about races because
> they simply do not play
On Wed, Jul 11, 2018 at 07:34:06AM +0800, Yang Shi wrote:
>
> Background:
> Recently, when we ran some vm scalability tests on machines with large memory,
> we ran into a couple of mmap_sem scalability issues when unmapping large
> memory
> space, please refer to https://lkml.org/lkml/2017/12/14/
On Wed 11-07-18 07:34:06, Yang Shi wrote:
>
> Background:
> Recently, when we ran some vm scalability tests on machines with large memory,
> we ran into a couple of mmap_sem scalability issues when unmapping large
> memory
> space, please refer to https://lkml.org/lkml/2017/12/14/733 and
> https:
Background:
Recently, when we ran some vm scalability tests on machines with large memory,
we ran into a couple of mmap_sem scalability issues when unmapping large memory
space, please refer to https://lkml.org/lkml/2017/12/14/733 and
https://lkml.org/lkml/2018/2/20/576.
History:
Then akpm sugg
13 matches
Mail list logo
