lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0911051558220.7668@V090114053VZO-1>
Date:	Thu, 5 Nov 2009 16:03:39 -0500 (EST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Andi Kleen <andi@...stfloor.org>
cc:	npiggin@...e.de, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	"hugh.dickins@...cali.co.uk" <hugh.dickins@...cali.co.uk>
Subject: Re: Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter
 instead

On Thu, 5 Nov 2009, Andi Kleen wrote:

> I'm not sure making all writers more expensive is really a good idea.

The scaling problems that I have seen (like simple concurrent page faults)
are due to lock contention on mmap_sem and due to counter updates in
mm_struct.

> 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()
related then simply going to larger increases may fix the issue??

> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ