On 4/12/19 9:14 AM, James Bottomley wrote: >> In the session I hope to resolve the question whether this is indeed >> the right thing to do for all kmalloc() users, without an explicit >> alignment requests, and if it's worth the potentially worse >> performance/fragmentation it would impose on a hypothetical new slab >> implementation for which it wouldn't be optimal to split power-of-two >> sized pages into power-of-two-sized objects (or whether there are any >> other downsides). > > I think so. The question is how aligned? explicit flushing arch's > definitely need at least cache line alignment when using kmalloc for > I/O and if allocations cross cache lines they have serious coherency > problems. The question of how much more aligned than this is > interesting ... I've got to say that the power of two allocator implies > same alignment as size and we seem to keep growing use cases that > assume this. Right, by "natural alignment" I meant exactly that - align to size for power-of-two sizes. > I'm not so keen on growing a separate API unless there's > a really useful mm efficiency in breaking the kmalloc alignment > assumptions. I'd argue there's not. > James >
