From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <47B49E62.6020808@cs.helsinki.fi> Date: Thu, 14 Feb 2008 22:02:42 +0200 From: Pekka Enberg MIME-Version: 1.0 Subject: Re: [patch 2/5] slub: Fallback to kmalloc_large for failing higher order allocs References: <20080214040245.915842795@sgi.com> <20080214040313.616551392@sgi.com> <20080214140614.GE17641@csn.ul.ie> <47B49520.4070201@cs.helsinki.fi> <47B49ADD.9010001@cs.helsinki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Mel Gorman , Nick Piggin , Andrew Morton , linux-mm@kvack.org List-ID: Christoph Lameter wrote: >> Aah, I see. I wonder if we can fix up allocate_slab() to try with a smaller >> order as long as the size allows that? The only problem I can see is >> s->objects but I think we can just move that to be a per-slab variable. So >> sort of variable-order slabs kind of a thing. > > Urgh. This is going to require a count of the maximum number of objects > per individual slab page. Adds more overhead to the fast path and means > that not all the slabs may have the same order. Which may in turn result > in a mix of order 3 2 1 pages. Not good for fragmentation. I think the > do order 3 always and then order 0 if we are in a bad fragmentation > state the best compromise. In particular because these bad fragmented > memory scenarios seems to be very difficult to produce and occur only in > specialized situations (f.e. minimal ram with lots of page pinned by I/O, > stuff like that). Ok, makes sense. Reviewed-by: Pekka Enberg to this patch and the kmem_cache_alloc equivalent (which you might as well fold into one patch). Thanks Christoph. Pekka -- 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