Hi Christoph,
On Sat, 5 Jan 2008, Pekka J Enberg wrote:
> > So, I have this silly memory profiler derived from the kleak patches by
> > the relayfs people and would love to try it out on an embedded workload
> > where SLUB memory footprint is terrible. Any suggestions?
On Sat, 5 Jan 2008, Christoph Lameter wrote:
> Good idea. But have you tried to look at slabinfo?
>
> Try to run
>
> slabinfo -t
>
> which will calculate the allocation overhead of the currently allocated
> objects in all slab caches.
Oh, I didn't know about that. It's great for looking at the current memory
footprint but not really suitable if you want to analyze allocation/free
patterns.
And I think we need to look at the patterns to figure out *where* and
*why* SLOB is better than SLUB and whether that can be fixed in SLUB or
the callers. For example, while it's obviously true that SLUB has
much higher internal fragmentation for kmalloc() than SLOB, it doesn't
matter as much if the allocations are short-lived. I don't think you can
extend the current SLUB debug mechanism to provide that but rather
"kmalloc accounting" is needed.
The problem with my patch, though, is that due to relayfs I cannot capture
events unless userspace is ready to read them which is why I am missing
all the data from boot (I think systemtap has this same limitation?). So
we need something like what Matt has except that it needs to keep track of
every *event* and userspace must be able to access them.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
