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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 15 Sep 2010 13:33:07 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Theodore Tso <tytso@....edu>
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 Wed, 15 Sep 2010, Theodore Tso 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.
> 

I'd love to have per-cache statistics that we could export without the 
cost of the extra memory from fragmented partial slabs.  You'd have to do 
this for every cache even if it's a "superslab", though, to avoid a branch 
in the fastpath to find the cpu slab.  I'm not sure if Pekka and Christoph 
will be happy with the allocation of kmem_cache structures for mergable 
caches and the increment of the statistic in the fastpath.
--
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/