[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1308341989.17300.511.camel@schen9-DESK>
Date: Fri, 17 Jun 2011 13:19:49 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Hugh Dickins <hughd@...gle.com>,
Andi Kleen <ak@...ux.intel.com>,
Shaohua Li <shaohua.li@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
David Miller <davem@...emloft.net>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Russell King <rmk@....linux.org.uk>,
Paul Mundt <lethal@...ux-sh.org>,
Jeff Dike <jdike@...toit.com>,
Richard Weinberger <richard@....at>,
"Luck, Tony" <tony.luck@...el.com>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Mel Gorman <mel@....ul.ie>, Nick Piggin <npiggin@...nel.dk>,
Namhyung Kim <namhyung@...il.com>,
"Shi, Alex" <alex.shi@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: REGRESSION: Performance regressions from switching
anon_vma->lock to mutex
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists