[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0710011406540.20071@schroedinger.engr.sgi.com>
Date: Mon, 1 Oct 2007 14:10:06 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Mel Gorman <mel@...net.ie>
cc: Nick Piggin <nickpiggin@...oo.com.au>,
Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, David Chinner <dgc@....com>,
Jens Axboe <jens.axboe@...cle.com>, akpm@...ux-foundation.org
Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK
On Fri, 28 Sep 2007, Mel Gorman wrote:
> Minimally, SLUB by default should continue to use order-0 pages. Peter has
> managed to bust order-1 pages with mem=128MB. Admittedly, it was a really
> hostile workload but the point remains. It was artifically worked around
> with min_free_kbytes (value set based on pageblock_order, could also have
> been artifically worked around by dropping pageblock_order) and he eventually
> caused order-0 failures so the workload is pretty damn hostile to everything.
SLAB default is order 1 so is SLUB default upstream.
SLAB does runtime detection of the amount of memory and configures the max
order correspondingly:
from mm/slab.c:
/*
* Fragmentation resistance on low memory - only use bigger
* page orders on machines with more than 32MB of memory.
*/
if (num_physpages > (32 << 20) >> PAGE_SHIFT)
slab_break_gfp_order = BREAK_GFP_ORDER_HI;
We could duplicate something like that for SLUB.
-
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