Re: [PATCH] mm, slab: extend kmalloc() alignment for non power-of-two sizes

[Vlastimil Babka]

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!