linux-kernel - Re: [PATCH v2 2/2] SLUB: Mark merged slab caches in /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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 15 Sep 2010 07:16:46 -0400
From:	Theodore Tso <tytso@....EDU>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Christoph Lameter <cl@...ux.com>
Subject: Re: [PATCH v2 2/2] SLUB: Mark merged slab caches in /proc/slabinfo

On Sep 14, 2010, at 8:02 PM, David Rientjes wrote:

> 
> I don't believe that we need to remove cache merging and allocate more 
> memory by default to be able to identify a particular cache using an 
> egregious amount of slab when troubleshooting a problem.  

Why not keep a separate accounting for each cache, even if we use the same set of pages for a set of slab cache?   It is *really* *useful* to be able to get that kind of debugging information without needing to reboot the system into some kind of magic debugging mode.  More than once I've had to debug a customer system where there was some kind of memory allocation problem, where rebooting wouldn't have been an option, or where rebooting would have destroyed the evidence.

It would seem to me that if there was a "super-slab" pointer in the slab cache structure, then if it turns out the slab system wants to merge a new slab cache with an existing one, you could instead allocate a "super slab" structure, copy information from the initial slab cache into the "super slab" and then set a pointer to the "super slab".   The only information that would be kept in the individual slab cache structures that have a non-zero "super slab" pointer would be the number of objects allocator for that particular object time.

This allows for us to track object class usage without needing to waste space caused by partially filled slab pages.   I think this would be a real win....

-- Ted

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