Re: [patch 1/3] slob: rework freelist handling

[Nick Piggin <npiggin@suse.de>]

On Wed, May 23, 2007 at 09:23:22PM -0700, Christoph Lameter wrote:
> On Thu, 24 May 2007, Nick Piggin wrote:
> 
> > > It would also work fine with SLUB? Its about 12k code + data on 
> > > x86_64. I doubt that this would be too much of an issue.
> > 
> > Well as I said, I am not the one to ask about whether SLUB could replace
> > SLOB or not. All else being equal, of course it is a good idea.
> > 
> > But what I think is clear is that SLOB simply uses memory more
> > efficiently than SLUB (in my test, anyway). I don't know how this can
> > still be in dispute?
> 
> You have shown that SLUB used more memory than SLOB after bootup on PPC64.
> But why is still an open question.

I'll take an educated guess and say that SLUB would have more external
fragmentation which would be especially pronounced in small memory
setups. Also, that SLUB's kmalloc slabs would suffer from a lot more
internal fragmentation too, which could be equally significant if not
more (I think this would become relatively more significant than external
fregmentation as you increased memory size).

If you don't think the test is very interesting, I could try any other
sort of test and with i386 or x86-64 if you like.


> It could be the way that SLOB can exploit the page for multiple object 
> sizes which creates the advantage. If that is the case then we can do 
> nothing with SLUB.
> 
> But there could still be excessive memory allocs with SLUB that we are not 
> aware of at this point. For example if the page size > 4k then SLUB will 
> use higher order allocs by default which will increase wastage.
 

--
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>