Messages in this thread | | | Date | Wed, 15 Sep 2010 13:33:07 -0700 (PDT) | From | David Rientjes <> | 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.
| |