On 7/2/24 11:13 PM, Roman Gushchin wrote: > On Tue, Jul 02, 2024 at 10:25:44PM +0200, Vlastimil Babka wrote: >> On 7/2/24 9:30 PM, Roman Gushchin wrote: >> > On Tue, Jul 02, 2024 at 05:58:01PM +0200, Vlastimil Babka wrote: >> > Hello Vlastimil, >> > >> > the idea and the implementation makes total sense to me. >> > >> > Do you have an estimate for the memory overhead it will typically introduce? >> >> There's no new overhead for the non-debug case as the layout already >> naturally has the same alignment as is now guaranteed. Debug has its own >> overhead so it's enabled only when needed, and this will not add much more. > > Got it, but can you, please, add this note with some explanation why it's true > to the commit message? Because it's not obvious and the commit message makes It's there but later: 1) doesn't change the current slab layout (and thus does not increase internal fragmentation) when slab debugging is not active > almost the opposite impression: > Slab allocators have been guaranteeing natural alignment for > power-of-two sizes <...>, while any other sizes are > aligned only to ARCH_KMALLOC_MINALIGN bytes. > > Should it be "guaranteed to be aligned" vs are actually aligned? Yes that's the case. Will update. >> >> > I don't think it will be too large though and actually can be compensated >> > by potential performance gains due to a better memory alignment. What do you >> > think? >> >> Yeah but again, the difference would be only in the debug case and >> performance gains there are not so interesting :) > > Acked-by: Roman Gushchin <roman.gushchin@xxxxxxxxx> Thanks! > Thanks!
