Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759568Ab1FQUT2 (ORCPT ); Fri, 17 Jun 2011 16:19:28 -0400 Received: from mga02.intel.com ([134.134.136.20]:17165 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756437Ab1FQUT1 (ORCPT ); Fri, 17 Jun 2011 16:19:27 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,383,1304319600"; d="scan'208";a="14888225" Subject: Re: REGRESSION: Performance regressions from switching anon_vma->lock to mutex From: Tim Chen To: Linus Torvalds Cc: Peter Zijlstra , Hugh Dickins , 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" In-Reply-To: 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> <1308334688.12801.19.camel@laptop> <1308335557.12801.24.camel@laptop> Content-Type: text/plain; charset="UTF-8" Date: Fri, 17 Jun 2011 13:19:49 -0700 Message-ID: <1308341989.17300.511.camel@schen9-DESK> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4006 Lines: 80 On Fri, 2011-06-17 at 11:39 -0700, Linus Torvalds wrote: > 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) > Linus, I've applied this patch, plus the other two patches on batching anon_vma clone and anon_vma unlink. This improved throughput further. I now see average throughput at 140.2% vs 2.6.39-vanilla over 10 runs. The mutex lock has also gone down to 3.7% of cpu in my profile. Certainly a great deal of improvements. To summarize, Throughput 2.6.39(vanilla) 100.0% 2.6.39+ra-patch 166.7% (+66.7%) 3.0-rc2(vanilla) 68.0% (-32%) 3.0-rc2+linus (v1) 115.7% (+15.7%) (anon_vma clone v1) 3.0-rc2+linus+softirq 86.2% (-17.3%) 3.0-rc2+linus (v2) 104.9% (+4.9%) (anon_vma clone v2) 3.0-rc2+linus (v3) 140.3% (+40.3%) (anon_vma clone v2 + unlink + chain_alloc_tweak) (Max-Min)/avg Standard Dev 2.6.39(vanilla) 3% 1.1% 2.6.39+ra-patch 3% 1.2% 3.0-rc2(vanilla) 20% 7.3% 3.0-rc2+linus 36% 12.2% 3.0-rc2+linus+softirq 40% 15.2% 3.0-rc2+linus (v2) 53% 14.8% 3.0-rc2+linus (v3) 27% 8.1% Thanks. Tim ------------Profile attached-------------- Profile from latest run 3.0-rc2+linus (v3): - 5.44% exim [kernel.kallsyms] [k] _raw_spin_lock_irqsave - _raw_spin_lock_irqsave + 87.81% cpupri_set + 5.67% release_pages + 1.71% pagevec_lru_move_fn + 1.31% try_to_wake_up + 0.85% get_page_from_freelist + 4.15% exim [kernel.kallsyms] [k] page_fault - 3.76% exim [kernel.kallsyms] [k] __mutex_lock_common.clone.5 - __mutex_lock_common.clone.5 - 99.97% __mutex_lock_slowpath - mutex_lock + 55.46% lock_anon_vma_root.clone.13 + 41.94% anon_vma_lock.clone.10 + 1.14% dup_mm + 1.02% unlink_file_vma + 2.44% exim [kernel.kallsyms] [k] unmap_vmas + 2.06% exim [kernel.kallsyms] [k] do_raw_spin_lock + 1.91% exim [kernel.kallsyms] [k] page_cache_get_speculative + 1.89% exim [kernel.kallsyms] [k] copy_page_c -- 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/