On Sat, Sep 28, 2019 at 01:12:49AM +0000, Christopher Lameter wrote: > However, the layout may be different due to another allocator that prefers > to arrange things differently (SLOB puts multiple objects of different > types in the same page to save memory), if we need to add data to these > objects (debugging info, new metadata about the object, maybe the memcg > pointer, maybe other things that may come up), or other innovative > approaches (such as putting data of different kmem caches that are > commonly used together in the same page to improve locality). If we ever do start putting objects of different sizes that are commonly allocated together in the same page (eg inodes & dentries), then those aren't going to be random kmalloc() allocation; they're going to be special kmem caches that can specify "I don't care about alignment". Also, we haven't done that. We've had a slab allocator for twenty years, and nobody's tried to do that. Maybe the co-allocation would be a net loss (I suspect). Or the gain is too small for the added complexity. Whatever way, this is a strawman. > The cost is an unnecessary petrification of the data layout of the memory > allocators. Yes, it is. And it's a cost I'm willing to pay in order to get the guarantee of alignment.
