From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id 8CC966B0012 for ; Fri, 17 Jun 2011 18:20:36 -0400 (EDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p5HMKSb4019340 for ; Fri, 17 Jun 2011 15:20:28 -0700 Received: from pzk6 (pzk6.prod.google.com [10.243.19.134]) by wpaz5.hot.corp.google.com with ESMTP id p5HMKPLv020512 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 17 Jun 2011 15:20:27 -0700 Received: by pzk6 with SMTP id 6so147pzk.12 for ; Fri, 17 Jun 2011 15:20:27 -0700 (PDT) Date: Fri, 17 Jun 2011 15:20:14 -0700 (PDT) From: Hugh Dickins Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex In-Reply-To: Message-ID: References: <1308097798.17300.142.camel@schen9-DESK> <1308156337.2171.23.camel@laptop> <1308163398.17300.147.camel@schen9-DESK> <1308169937.15315.88.camel@twins> <4DF91CB9.5080504@linux.intel.com> <1308172336.17300.177.camel@schen9-DESK> <1308173849.15315.91.camel@twins> <1308255972.17300.450.camel@schen9-DESK> <1308310080.2355.19.camel@twins> <1308334688.12801.19.camel@laptop> <1308335557.12801.24.camel@laptop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Peter Zijlstra , Hugh Dickins , Tim Chen , Andi Kleen , Shaohua Li , Andrew Morton , KOSAKI Motohiro , Benjamin Herrenschmidt , David Miller , Martin Schwidefsky , Russell King , Paul Mundt , Jeff Dike , Richard Weinberger , "Luck, Tony" , KAMEZAWA Hiroyuki , Mel Gorman , Nick Piggin , Namhyung Kim , "Shi, Alex" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "Rafael J. Wysocki" On Fri, 17 Jun 2011, Linus Torvalds wrote: > On Fri, Jun 17, 2011 at 11:32 AM, Peter Zijlstra wrote: > > > > something like so I guess, completely untested etc.. > > Having gone over it a bit more, I actually think I prefer to just > special-case the allocation instead. > > We already have to drop the anon_vma lock for the "out of memory" > case, and a slight re-organization of clone_anon_vma() makes it easy > to just first try a NOIO allocation with the lock still held, and then > if that fails do the "drop lock, retry, and hard-fail" case. > > IOW, something like the attached (on top of the patches already posted > except for your memory reclaim thing) > > Hugh, does this fix the lockdep issue? Yes, that fixed the lockdep issue, and ran nicely under load for an hour. I agree that it's better to do this GFP_NOWAIT and fallback, than trylock the anon_vma. And I'm happy that you've still got that WARN_ON_ONCE(root) in: I do not have a fluid mental model of the anon_vma_chains, get lost there; and though it's obvious that we must have the same anon_vma->root going down the same_anon_vma list, I could not put my finger on a killer demonstration for why the same has to be true of the same_vma list. But I've not seen your WARN_ON_ONCE fire, and it's hard to imagine how there could be more than one root in the whole bundle of lists. Hugh -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org