On Wed 11-07-18 15:49:54, Andrew Morton wrote: > On Wed, 11 Jul 2018 12:33:12 +0200 Michal Hocko <mho...@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
