From: Christoph Lameter <clameter@sgi.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, apw@shadowen.org,
Martin Bligh <mbligh@mbligh.org>
Subject: Re: [PATCH] Page allocator: Get rid of the list of cold pages
Date: Wed, 21 Nov 2007 18:20:49 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0711211812060.4858@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20071122014455.GH31674@csn.ul.ie>
On Thu, 22 Nov 2007, Mel Gorman wrote:
> And the results were better as well. Running one instance per-CPU, the
> joined lists ignoring temperature was marginally faster than no-PCPU or
> the hotcold-PCPU up to 0.5MB which roughly corresponds to the some of L1
> caches of the CPUs. At higher sizes, it starts to look slower but even
> at 8MB files, it is by a much smaller amount. With list manuipulations,
> it is about 0.3 seconds slower. With just the lists joined, it's 0.1
> seconds and I think the patch could simplify the paths more than what we
> have currently. The full graph is at
Hmmm... This sounds like we could improve the situation by just having
single linked lists? The update effort is then much less.
Here is a matrix of page allocator performance (2.6.24-rc2 with
sparsemem) done with my page allocator test from
http://git.kernel.org/?p=linux/kernel/git/christoph/slab.git;a=log;h=tests
All tests are in cycles
Single thread testing
=====================
1. Repeatedly allocate then free test
1000 times alloc_page(,0) -> 616 cycles __free_pages(,0)-> 295 cycles
1000 times alloc_page(,1) -> 576 cycles __free_pages(,1)-> 341 cycles
1000 times alloc_page(,2) -> 712 cycles __free_pages(,2)-> 380 cycles
1000 times alloc_page(,3) -> 966 cycles __free_pages(,3)-> 467 cycles
1000 times alloc_page(,4) -> 1435 cycles __free_pages(,4)-> 662 cycles
1000 times alloc_page(,5) -> 2201 cycles __free_pages(,5)-> 1044 cycles
1000 times alloc_page(,6) -> 3770 cycles __free_pages(,6)-> 2550 cycles
1000 times alloc_page(,7) -> 6781 cycles __free_pages(,7)-> 7652 cycles
1000 times alloc_page(,8) -> 13592 cycles __free_pages(,8)-> 17999 cycles
1000 times alloc_page(,9) -> 27970 cycles __free_pages(,9)-> 36335 cycles
1000 times alloc_page(,10) -> 58586 cycles __free_pages(,10)-> 72323 cycles
2. alloc/free test
1000 times alloc( ,0)/free -> 349 cycles
1000 times alloc( ,1)/free -> 531 cycles
1000 times alloc( ,2)/free -> 571 cycles
1000 times alloc( ,3)/free -> 663 cycles
1000 times alloc( ,4)/free -> 853 cycles
1000 times alloc( ,5)/free -> 1220 cycles
1000 times alloc( ,6)/free -> 2092 cycles
1000 times alloc( ,7)/free -> 3640 cycles
1000 times alloc( ,8)/free -> 6524 cycles
1000 times alloc( ,9)/free -> 12421 cycles
1000 times alloc( ,10)/free -> 30197 cycles
This shows that actually order 1 allocations that bypass the pcp lists are
faster! We save the overhead of extracting pages from the buddy lists and
putting them into the pcp.
The alloc free tests shows that the pcp lists are effective when
cache hot.
Concurrent allocs
=================
Page alloc N*alloc N*free(0): 0=8266/8635 1=9667/8129 2=8501/8585 3=9485/8129 4=7870/8635 5=9761/7957 6=7687/8456 7=9749/7681 Average=8873/8276
Page alloc N*alloc N*free(1): 0=28917/22006 1=30057/26753 2=28930/23925
3=30099/26779 4=28845/23717 5=30166/26733 6=28250/23744 7=30149/26677
Average=29427/25042
Page alloc N*alloc N*free(2): 0=25316/23430 1=28749/26527 2=24858/22929
3=28804/26636 4=24871/23368 5=28496/26621 6=25188/22057 7=28730/26228
Average=26877/24725
Page alloc N*alloc N*free(3): 0=22414/23618 1=26397/27478 2=22359/24237
3=26413/27060 4=22328/24021 5=26098/27879 6=22391/23731 7=26322/27802
Average=24340/25728
Page alloc N*alloc N*free(4): 0=24922/26358 1=28126/30480 2=24733/26177
3=28267/30540 4=25016/25688 5=28150/30563 6=24938/24902 7=28247/30650
Average=26550/28170
Page alloc N*alloc N*free(5): 0=25211/27315 1=29504/32577 2=25796/27681
3=29565/32272 4=26056/26588 5=29471/32728 6=25967/26619 7=29447/32744
Average=27627/29816
The difference between order and 1 shows that pcp lists are effective at
reducing zone lru lock overhead. The difference is factor 3 at 8p.
----Fastpath---
Page N*(alloc free)(0): 0=363 1=360 2=379 3=363 4=362 5=363 6=363 7=360
Average=364
Page N*(alloc free)(1): 0=41014 1=44448 2=40416 3=44367 4=40980 5=44411
6=40760 7=44265 Average=42583
Page N*(alloc free)(2): 0=42686 1=45588 2=42202 3=45509 4=42733 5=45561
6=42716 7=45485 Average=44060
Page N*(alloc free)(3): 0=40567 1=43556 2=39699 3=43404 4=40435 5=43274
6=39614 7=43545 Average=41762
Page N*(alloc free)(4): 0=43310 1=45097 2=43326 3=45405 4=43219 5=45372
6=42492 7=45378 Average=44200
Page N*(alloc free)(5): 0=42765 1=45370 2=42029 3=44979 4=42567 5=45336
6=42929 7=45016 Average=43874
This is just allocating and freeing the same page all the time. Here the
pcps are orders of magnitude faster.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-11-22 2:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-14 19:52 Christoph Lameter
2007-11-14 21:13 ` Christoph Lameter
2007-11-16 0:27 ` Andrew Morton
2007-11-21 22:20 ` Mel Gorman
2007-11-21 22:28 ` Christoph Lameter
2007-11-21 22:54 ` Mel Gorman
2007-11-21 22:39 ` Christoph Lameter
2007-11-21 23:00 ` Mel Gorman
2007-11-21 23:29 ` Christoph Lameter
2007-11-21 23:34 ` Christoph Lameter
2007-11-21 23:58 ` Mel Gorman
2007-11-22 0:06 ` Christoph Lameter
2007-11-22 1:44 ` Mel Gorman
2007-11-22 2:20 ` Christoph Lameter [this message]
2007-11-21 23:23 ` Andrew Morton
2007-11-21 23:51 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0711211812060.4858@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@mbligh.org \
--cc=mel@csn.ul.ie \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox