From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422634Ab1FPWAl (ORCPT ); Thu, 16 Jun 2011 18:00:41 -0400 Received: from mga09.intel.com ([134.134.136.24]:17244 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161002Ab1FPWAk (ORCPT ); Thu, 16 Jun 2011 18:00:40 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,377,1304319600"; d="scan'208";a="14491987" Message-ID: <4DFA7D07.2010207@linux.intel.com> Date: Thu, 16 Jun 2011 15:00:39 -0700 From: Andi Kleen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Linus Torvalds CC: Tim Chen , Peter Zijlstra , 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" Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Ok, I bet it doesn't make them a non-issue, but if doing this in > anon_vma_clone() helped a lot, then doing the exact same pattern in > unlink_anon_vmas() hopefully helps some more. Hi Linus, I did essentially the same thing (just in a less elegant, more paranoid way) in my old batching patches. http://comments.gmane.org/gmane.linux.kernel.mm/63130 They made it a bit better, but overall it's still much worse than 2.6.35 (.36 introduced the root chain locking). I guess we'll see if it can recover mutex though, but I'm not optimistic. -Andi