Slab reclaim

Really? I accept that all three of these are important. I do wonder if everyone would agree with that particular ordering. For some people, memory hotplug is doubtlessly an important issue. For many others, it is completely irrelevant.

> That avoids what was described as the main downside of Lameter's scheme: the need to add mobility to each type of slab-allocated object.

Is that *really* a need? Often there are just a few slabs which cause most fragmentation. Adding mobility (or the simpler "selective freeing") to just those would presumably bring most of the benefit. Others could be added as developers are motivated.

> objects allocated with kmalloc(), which are otherwise problematic.

Problematic in theory, certainly. Problematic in practice? I'd like to see evidence.

One allocation that occurs to me as being problematic is the kmalloc() in __d_alloc().
When a filename is longer than DNAME_INLINE_LEN (32), a kmalloc is used to allocate extra memory to attach to the dentry to hold the name.
If the slab holding that name wanted to free up the page, something would need to be able to link
back to the dentry. That probably means creating a new slab with entries containing both the name and the dentry pointer. A bit of a pain, but quite do-able.

So yes, kmalloc() can be problematic. But once the problems are identified, they can also be solved.

I agree with Lameter here:

> the time has come to merge it and start making use of it.