From: Andi Kleen <andi@firstfloor.org>
To: Christoph Lameter <cl@linux-foundation.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: [RFC MM] Accessors for mm locking
Date: Thu, 05 Nov 2009 21:52:12 +0100 [thread overview]
Message-ID: <87vdho7kzn.fsf@basil.nowhere.org> (raw)
In-Reply-To: <alpine.DEB.1.10.0911051417370.24312@V090114053VZO-1> (Christoph Lameter's message of "Thu, 5 Nov 2009 14:19:25 -0500 (EST)")
Christoph Lameter <cl@linux-foundation.org> writes:
> From: Christoph Lameter <cl@linux-foundation.org>
> Subject: [RFC MM] Accessors for mm locking
>
> Scaling of MM locking has been a concern for a long time. With the arrival of
> high thread counts in average business systems we may finally have to do
> something about that.
Thanks for starting to think about that. Yes, this is definitely
something that needs to be addressed.
> Index: linux-2.6/arch/x86/mm/fault.c
> ===================================================================
> --- linux-2.6.orig/arch/x86/mm/fault.c 2009-11-05 13:02:35.000000000 -0600
> +++ linux-2.6/arch/x86/mm/fault.c 2009-11-05 13:02:41.000000000 -0600
> @@ -758,7 +758,7 @@ __bad_area(struct pt_regs *regs, unsigne
> * Something tried to access memory that isn't in our memory map..
> * Fix it, but check if it's kernel or user first..
> */
> - up_read(&mm->mmap_sem);
> + mm_reader_unlock(mm);
My assumption was that a suitable scalable lock (or rather multi locks)
would need to know about the virtual address, or at least the VMA.
As in doing range locking for different address space areas.
So this simple abstraction doesn't seem to be enough to really experiment?
Or what did you have in mind for improving the locking without using
ranges?
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
--
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-05 20:52 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 19:19 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
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 ` Andi Kleen [this message]
2009-11-05 20:57 ` [RFC MM] Accessors for mm locking 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=87vdho7kzn.fsf@basil.nowhere.org \
--to=andi@firstfloor.org \
--cc=cl@linux-foundation.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