Re: Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter instead

[Andi Kleen <andi@firstfloor.org>]

On Thu, Nov 05, 2009 at 04:03:39PM -0500, Christoph Lameter wrote:
> > For example it will definitely impact the AIM7 multi brk() issue
> > or the mysql allocation case, which are all writer intensive. I assume
> > doing a lot of mmaps/brks in parallel is not that uncommon.
> 
> No its not that common. Page faults are much more common. The AIM7 seems
> to be an artificial case? What does mysql do for allocation? If its brk()

AIM7 is artificial yes, but I suspect similar problems (to a less
extreme degree) are in other workloads.

> related then simply going to larger increases may fix the issue??

For mysql it's mmap through malloc(). There has been some tuning in
glibc for it. But I suspect it's a more general problem that will
still need kernel improvements.

> 
> > My thinking was more that we simply need per VMA locking or
> > some other per larger address range locking. Unfortunately that
> > needs changes in a lot of users that mess with the VMA lists
> > (perhaps really needs some better abstractions for VMA list management
> > first)
> 
> We have range locking through the distribution of the ptl for systems with
> more than 4 processors. One can use that today to lock ranges of the
> address space.

Yes but all the major calls still take mmap_sem, which is not ranged.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.