Re: [patch 2/5] slub: Fallback to kmalloc_large for failing higher order allocs

[Pekka Enberg <penberg@cs.helsinki.fi>]

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 <penberg@cs.helsinki.fi>

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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>