From: Christoph Lameter <cl@linux-foundation.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: npiggin@suse.de, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Tejun Heo <tj@kernel.org>,
Ingo Molnar <mingo@elte.hu>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
"hugh.dickins@tiscali.co.uk" <hugh.dickins@tiscali.co.uk>
Subject: Re: Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter instead
Date: Fri, 6 Nov 2009 12:54:50 -0500 (EST) [thread overview]
Message-ID: <alpine.DEB.1.10.0911061249170.5187@V090114053VZO-1> (raw)
In-Reply-To: <20091106174439.GB819@basil.fritz.box>
On Fri, 6 Nov 2009, Andi Kleen wrote:
> On Fri, Nov 06, 2009 at 12:08:54PM -0500, Christoph Lameter wrote:
> > On Fri, 6 Nov 2009, Andi Kleen wrote:
> >
> > > Yes but all the major calls still take mmap_sem, which is not ranged.
> >
> > But exactly that issue is addressed by this patch!
>
> Major calls = mmap, brk, etc.
Those are rare. More frequently are for faults, get_user_pages and
the like operations that are frequent.
brk depends on process wide settings and has to be
serialized using a processor wide locks.
mmap and other address space local modification may be able to avoid
taking mmap write lock by taking the read lock and then locking the
ptls in the page struct relevant to the address space being modified.
This is also enabled by this patchset.
> Only for page faults, not for anything that takes it for write.
>
> Anyways the better reader lock is a step in the right direction, but
> I have my doubts it's a good idea to make write really slow here.
The bigger the system the larger the problems with mmap. This is one key
scaling issue important for the VM. We can work on that. I have a patch
here that restricts the per cpu checks to only those cpus on which the
process has at some times run before.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-11-06 17:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 19:19 [RFC MM] Accessors for mm locking Christoph Lameter
2009-11-05 19:20 ` Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter instead Christoph Lameter
2009-11-05 20:56 ` Andi Kleen
2009-11-05 21:03 ` Christoph Lameter
2009-11-06 7:39 ` Andi Kleen
2009-11-06 17:08 ` Christoph Lameter
2009-11-06 17:44 ` Andi Kleen
2009-11-06 17:54 ` Christoph Lameter [this message]
2009-11-10 6:21 ` KOSAKI Motohiro
2009-11-10 9:19 ` Andi Kleen
2009-11-06 18:53 ` [RFC MM] mmap_sem scaling: only scan cpus used by an mm Christoph Lameter
2009-11-06 19:14 ` Andi Kleen
2009-11-06 19:45 ` Christoph Lameter
2009-11-05 22:05 ` [RFC MM] swap counters Christoph Lameter
2009-11-06 2:54 ` KAMEZAWA Hiroyuki
2009-11-06 15:41 ` Subject: [RFC MM] mmap_sem scaling: Use mutex and percpu counter instead Minchan Kim
2009-11-06 17:10 ` Christoph Lameter
2009-11-07 4:19 ` Minchan Kim
2009-11-10 20:20 ` Christoph Lameter
2009-11-05 20:52 ` [RFC MM] Accessors for mm locking Andi Kleen
2009-11-05 20:57 ` Christoph Lameter
2009-11-17 6:42 ` Zhang, Yanmin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.1.10.0911061249170.5187@V090114053VZO-1 \
--to=cl@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hugh.dickins@tiscali.co.uk \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox