Messages in this thread | | | Date | Fri, 6 Nov 2009 08:39:46 +0100 | From | Andi Kleen <> | Subject | Re: Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter instead |
| |
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.
| |