Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753808Ab0AGTUp (ORCPT ); Thu, 7 Jan 2010 14:20:45 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753783Ab0AGTUo (ORCPT ); Thu, 7 Jan 2010 14:20:44 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]:51244 "EHLO e6.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753789Ab0AGTUn (ORCPT ); Thu, 7 Jan 2010 14:20:43 -0500 Date: Thu, 7 Jan 2010 11:20:35 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Peter Zijlstra , Christoph Lameter , Arjan van de Ven , KAMEZAWA Hiroyuki , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "minchan.kim@gmail.com" , "hugh.dickins" , Nick Piggin , Ingo Molnar Subject: Re: [RFC][PATCH 6/8] mm: handle_speculative_fault() Message-ID: <20100107192035.GO6764@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20100104182813.753545361@chello.nl> <20100105054536.44bf8002@infradead.org> <20100105192243.1d6b2213@infradead.org> <1262884960.4049.106.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 73 On Thu, Jan 07, 2010 at 10:44:13AM -0800, Linus Torvalds wrote: > > > On Thu, 7 Jan 2010, Linus Torvalds wrote: > > > > For example: there's no real reason why we take mmap_sem for writing when > > extending an existing vma. And while 'brk()' is a very oldfashioned way of > > doing memory management, it's still quite common. So rather than looking > > at subtle lockless algorithms, why not look at doing the common cases of > > an extending brk? Make that one take the mmap_sem for _reading_, and then > > do the extending of the brk area with a simple cmpxchg or something? > > I didn't use cmpxchg, because we actually want to update both > 'current->brk' _and_ the vma->vm_end atomically, so here's a totally > untested patch that uses the page_table_lock spinlock for it instead (it > could be a new spinlock, not worth it). > > It's also totally untested and might be horribly broken. But you get the > idea. > > We could probably do things like this in regular mmap() too for the > "extend a mmap" case. brk() is just especially simple. One question on the final test... > Linus > > --- > mm/mmap.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++++++------- > 1 files changed, 79 insertions(+), 10 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index ee22989..3d07e5f 100644 [ . . . ] > + if (!vma) > + goto slow_case; > + > + spin_lock(&mm->page_table_lock); > + if (vma->vm_end == cur_brk) { > + vma->vm_end = brk; > + mm->brk = brk; > + cur_brk = brk; > + } > + spin_unlock(&mm->page_table_lock); > + > + if (cur_brk != brk) Can this be "if (cur_brk < brk)"? Seems like it should, given the earlier tests, but I don't claim to understand the VM code. Thanx, Paul > + goto slow_case; > + > +out: > + up_read(&mm->mmap_sem); > + return cur_brk; > + > +slow_case: > + up_read(&mm->mmap_sem); > + return slow_brk(brk); > +} > + > #ifdef DEBUG_MM_RB > static int browse_rb(struct rb_root *root) > { -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/