]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
mm: fix migratetype bug which slowed swapping
authorHugh Dickins <hugh.dickins@tiscali.co.uk>
Fri, 29 Jan 2010 17:46:34 +0000 (17:46 +0000)
committerGreg Kroah-Hartman <gregkh@suse.de>
Tue, 9 Feb 2010 12:50:49 +0000 (04:50 -0800)
commit0b3bf81197f05e1bf0ed93c5f2525030b127faaa
tree8e494138f0ccb106a9c1090978c3cbed8495dc48
parent629527c562c1cfae09776c8baeb9a8a273dc10e6
mm: fix migratetype bug which slowed swapping

commit a7016235a61d520e6806f38129001d935c4b6661 upstream.

After memory pressure has forced it to dip into the reserves, 2.6.32's
5f8dcc21211a3d4e3a7a5ca366b469fb88117f61 "page-allocator: split per-cpu
list into one-list-per-migrate-type" has been returning MIGRATE_RESERVE
pages to the MIGRATE_MOVABLE free_list: in some sense depleting reserves.

Fix that in the most straightforward way (which, considering the overheads
of alternative approaches, is Mel's preference): the right migratetype is
already in page_private(page), but free_pcppages_bulk() wasn't using it.

How did this bug show up?  As a 20% slowdown in my tmpfs loop kbuild
swapping tests, on PowerMac G5 with SLUB allocator.  Bisecting to that
commit was easy, but explaining the magnitude of the slowdown not easy.

The same effect appears, but much less markedly, with SLAB, and even
less markedly on other machines (the PowerMac divides into fewer zones
than x86, I think that may be a factor).  We guess that lumpy reclaim
of short-lived high-order pages is implicated in some way, and probably
this bug has been tickling a poor decision somewhere in page reclaim.

But instrumentation hasn't told me much, I've run out of time and
imagination to determine exactly what's going on, and shouldn't hold up
the fix any longer: it's valid, and might even fix other misbehaviours.

Signed-off-by: Hugh Dickins <hugh.dickins@tiscali.co.uk>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
mm/page_alloc.c