lkml.org 
[lkml]   [2018]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC v4 0/3] mm: zap pages with read mmap_sem in munmap for large mapping
On Wed 11-07-18 15:49:54, Andrew Morton wrote:
> On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko <mhocko@kernel.org> 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_sem to cleanup vmas.
> > >
> > > But, we can't call MADV_DONTNEED directly, since there are two major drawbacks:
> > > * The unexpected state from PF if it wins the race in the middle of munmap.
> > > It may return zero page, instead of the content or SIGSEGV.
> > > * Can’t handle VM_LOCKED | VM_HUGETLB | VM_PFNMAP and uprobe mappings, which
> > > is a showstopper from akpm
> >
> > I do not really understand why this is a showstopper. This is a mere
> > optimization. VM_LOCKED ranges are usually not that large. VM_HUGETLB
> > can be quite large alright but this should be doable on top. Is there
> > any reason to block any "cover most mappings first" patch?
>
> Somebody somewhere is going to want to unmap vast mlocked regions and
> they're going to report softlockup warnings. So we shouldn't implement
> something which can't address these cases. Maybe it doesn't do so in
> the first version, but we should at least have a plan to handle all
> cases.

Absolutely. I was just responding to the "showstopper" part. This is
improving some cases but it shouldn't make others worse so going
incremental should be perfectly reasonable.
--
Michal Hocko
SUSE Labs
\
 
 \ /
  Last update: 2018-07-15 22:05    [W:0.065 / U:0.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site