Re: [RFC v10 PATCH 0/3] mm: zap pages with read mmap_sem in munmap for large mapping

On Mon, Sep 17, 2018 at 01:00:58PM -0700, Yang Shi wrote: > On 9/15/18 3:10 AM, Matthew Wilcox wrote: > > Something I've been wondering about for a while is whether we should "sort" > > the readers together. ie if the acquirers look like this: > > > > A write > > B read > > C read > > D write > >

Re: [RFC v10 PATCH 0/3] mm: zap pages with read mmap_sem in munmap for large mapping

On 9/15/18 3:10 AM, Matthew Wilcox wrote: On Sat, Sep 15, 2018 at 04:34:56AM +0800, Yang Shi wrote: Regression and performance data: Did the below regression test with setting thresh to 4K manually in the code: * Full LTP * Trinity (munmap/all vm syscalls) * Stress-ng: mmap/mmapfork/

Re: [RFC v10 PATCH 0/3] mm: zap pages with read mmap_sem in munmap for large mapping

On Sat, Sep 15, 2018 at 04:34:56AM +0800, Yang Shi wrote: > Regression and performance data: > Did the below regression test with setting thresh to 4K manually in the code: > * Full LTP > * Trinity (munmap/all vm syscalls) > * Stress-ng: mmap/mmapfork/mmapfixed/mmapaddr/mmapmany/vm > * mm-t

[RFC v10 PATCH 0/3] mm: zap pages with read mmap_sem in munmap for large mapping

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