From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Lameter Subject: Re: [15/17] SLUB: Support virtual fallback via SLAB_VFALLBACK Date: Mon, 1 Oct 2007 14:10:06 -0700 (PDT) Message-ID: References: <20070919033605.785839297@sgi.com> <20070919033643.763818012@sgi.com> <200709280742.38262.nickpiggin@yahoo.com.au> <20070928210527.GB30404@skynet.ie> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Nick Piggin , Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, David Chinner , Jens Axboe , akpm@linux-foundation.org To: Mel Gorman Return-path: Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:43581 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752700AbXJAVKH (ORCPT ); Mon, 1 Oct 2007 17:10:07 -0400 In-Reply-To: <20070928210527.GB30404@skynet.ie> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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.