On Thu, Sep 3, 2015 at 9:02 AM, Dave Chinner <dchinner@xxxxxxxxxx> wrote: > One of the reasons slab caches exist is to separate objects of > identical characteristics from the heap allocator so that they are > all grouped together in memory and so can be allocated/freed > efficiently. This helps prevent heap fragmentation, allows objects > to pack as tightly together as possible, gives direct measurement of > the number of objects, the memory usage, the fragmentation factor, > etc. Containment of memory corruption is another historical reason > for slab separation (proof: current memory debugging options always > causes slab separation). > > Slab merging is the exact opposite of this - we're taking homogenous > objects and mixing them with other homogneous containing different > objects with different life times. Indeed, we are even mixing them > back into the slabs used for the heap, despite the fact the original > purpose of named slabs was to separate allocation from the heap... > > Don't get me wrong - this isn't necessarily bad - but I'm just > pointing out that slab merging is doing the opposite of what slabs > were originally intended for. Indeed, a lot of people use slab > caches just because it's anice encapsulation, not for any specific > performance, visibility or anti-fragmentation purposes. I have no > problems with automatically merging slabs created like this. Yes, absolutely. Alternative to slab merging is to actually reduce the number of caches we create in the first place and use kmalloc() wherever possible. - Pekka -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>