From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail137.messagelabs.com (mail137.messagelabs.com [216.82.249.19]) by kanga.kvack.org (Postfix) with ESMTP id 8DCCD6B0012 for ; Fri, 17 Jun 2011 12:54:02 -0400 (EDT) Received: from mail-wy0-f169.google.com (mail-wy0-f169.google.com [74.125.82.169]) (authenticated bits=0) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id p5HGrY4o007434 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for ; Fri, 17 Jun 2011 09:53:35 -0700 Received: by wyf19 with SMTP id 19so2490061wyf.14 for ; Fri, 17 Jun 2011 09:53:34 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1308310080.2355.19.camel@twins> References: <1308097798.17300.142.camel@schen9-DESK> <1308101214.15392.151.camel@sli10-conroe> <1308138750.15315.62.camel@twins> <20110615161827.GA11769@tassilo.jf.intel.com> <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> From: Linus Torvalds Date: Fri, 17 Jun 2011 09:36:48 -0700 Message-ID: Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Peter Zijlstra Cc: Tim Chen , Andi Kleen , Shaohua Li , Andrew Morton , Hugh Dickins , 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, Jun 17, 2011 at 4:28 AM, Peter Zijlstra wrote: > > Something like so? Compiles and runs the benchmark in question. Yup. Except I really think that test for a NULL anon_vma should go away. If an avc entry has a NULL anon_vma, something is seriously wrong. The comment about anon_vma_fork failure is definitely just bogus: the anon_vma is allocated before the avc entry, so there's no way a avc can have a NULL anon_vma from there. But yes, your patch is cleaner than the one I was playing around with (your "remove if not list empty" is prettier than what I was toying with - having a separate flag in the avc) Tim, can you test Peter's (second - the cleaned up one) patch on top of mine, and see if that helps things further? The only thing I don't love about the batching is that we now do hold the lock over some situations where we _could_ have allowed concurrency (notably some avc allocations), but I think it's a good trade-off. And walking the list twice at unlink_anon_vmas() should be basically free. Linus -- 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