Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755441Ab1FOVih (ORCPT ); Wed, 15 Jun 2011 17:38:37 -0400 Received: from merlin.infradead.org ([205.233.59.134]:38599 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755056Ab1FOVif convert rfc822-to-8bit (ORCPT ); Wed, 15 Jun 2011 17:38:35 -0400 Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex From: Peter Zijlstra To: Tim Chen Cc: Andi Kleen , Shaohua Li , Andrew Morton , Linus Torvalds , 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" In-Reply-To: <1308172336.17300.177.camel@schen9-DESK> 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Date: Wed, 15 Jun 2011 23:37:29 +0200 Message-ID: <1308173849.15315.91.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 840 Lines: 19 On Wed, 2011-06-15 at 14:12 -0700, Tim Chen wrote: > Thanks to Andi for providing the info. We've used this workaround in > our testing so it will not mask true kernel scaling bottlenecks. http://programming.kicks-ass.net/sekrit/39-2.txt.bz2 http://programming.kicks-ass.net/sekrit/tip-2.txt.bz2 tip+sirq+linus is still slightly faster than .39 here, although removing that sysconf() wreckage closed the gap considerably (needing to know the number of cpus to optimize locking sounds like a trainwreck all of its own, needing it _that_ often instead of just once at startup is even worse). -- 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/