From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 4 Mar 2008 13:01:26 -0600 From: Matt Mackall Subject: Re: [patch 0/8] slub: Fallback to order 0 and variable order slab support Message-ID: <20080304190126.GM10223@waste.org> References: <20080229044803.482012397@sgi.com> <20080304122008.GB19606@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080304122008.GB19606@csn.ul.ie> Sender: owner-linux-mm@kvack.org Return-Path: To: Mel Gorman Cc: Christoph Lameter , Pekka Enberg , linux-mm@kvack.org List-ID: On Tue, Mar 04, 2008 at 12:20:08PM +0000, Mel Gorman wrote: > On (28/02/08 20:48), Christoph Lameter didst pronounce: > > This is the patchset that was posted two weeks ago modified according > > to the feedback that Pekka gave. I would like to put these patches > > into mm. > > > > I haven't reviewed the patches properly but I put them through a quick test > against 2.6.25-rc3 to see what the performnace was like and the superpage > allocation success rates were like. Performance wise, it looked like > > Loss to Gain > Kernbench Elapsed time -0.64% 0.32% > Kernbench Total time -0.61% 0.48% > Hackbench sockets-12 clients -2.95% 5.13% > Hackbench pipes-12 clients -16.95% 9.27% > TBench 4 clients -1.98% 8.2% > DBench 4 clients (ext2) -5.9% 7.99% > > So, running with the high orders is not a clear-cut win to my eyes. What > did you test to show that it was a general win justifying a high-order by > default? From looking through, tbench seems to be the only obvious one to > gain but the rest, it is not clear at all. I'll try give sysbench a spin > later to see if it is clear-cut. > > However, in *all* cases, superpage allocations were less successful and in > some cases it was severely regressed (one machine went from 81% success rate > to 36%). Sufficient statistics are not gathered to see why this happened > in retrospect but my suspicion would be that high-order RECLAIMABLE and > UNMOVABLE slub allocations routinely fall back to the less fragmented > MOVABLE pageblocks with these patches - something that is normally a very > rare event. This change in assumption hurts fragmentation avoidance and > chances are the long-term behaviour of these patches is not great. > > If this guess is correct, using a high-order size by default is a bad plan > and it should only be set when it is known that the target workload benefits > and superpage allocations are not a concern. Alternative, set high-order by > default only for a limited number of caches that are RECLAIMABLE (or better > yet ones we know can be directly reclaimed with the slub-defrag patches). > > As it is, this is painful from a fragmentation perspective and the > performance win is not clear-cut. Thanks for looking at this, Mel. Could you try testing.. umm... slub_max_order=1? That's never going to get us more than one more object per slab, but if we can go from 1 per page to 1.5 per page, it might be worth it. Task structs are roughly in that size domain. -- Mathematics is the supreme nostalgia of our time. -- 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: email@kvack.org