linux-kernel - Re: [PATCH] procfs: provide slub's /proc/slabinfo

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0801072157550.31715@sbz-30.cs.Helsinki.FI>
Date:	Mon, 7 Jan 2008 22:12:44 +0200 (EET)
From:	Pekka J Enberg <penberg@...helsinki.fi>
To:	Christoph Lameter <clameter@....com>
cc:	Matt Mackall <mpm@...enic.com>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Hugh Dickins <hugh@...itas.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	zanussi@...ibm.com
Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/