lkml.org 
[lkml]   [2008]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] procfs: provide slub's /proc/slabinfo
> I still have trouble to see that SLOB still has much to offer. An embedded 
> allocator that in many cases has more allocation overhead than the default
> one? Ok you still have advantages if allocations are rounded up to the
> next power of two for a kmalloc and because of the combining of different
> types of allocations in a single slab if there are an overall small number
> of allocations. If one would create a custom slab for the worst problems
> there then this may also go away.

I suspect it would be a good idea anyways to reevaluate the power of two
slabs. Perhaps a better distribution can be found based on some profiling?
I did profile kmalloc using a systemtap script some time ago but don't
remember the results exactly, but iirc it looked like it could be improved.

A long time ago i also had some code to let the network stack give hints
about its MMUs to slab to create fitting slabs for packets. But that
was never really pushed forward because it turned out it didn't help
much for the most common 1.5K MTU -- always only two packets fit into
a page.

-Andi
>


\
 
 \ /
  Last update: 2008-01-04 03:45    [W:0.173 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site