lkml.org 
[lkml]   [2010]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2 2/2] SLUB: Mark merged slab caches in /proc/slabinfo
From
Date

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



\
 
 \ /
  Last update: 2010-09-15 13:25    [from the cache]
©2003-2011 Jasper Spaans