[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <df4ce65f-2d1d-4dc2-b91b-d5373dfdd35c@suse.cz>
Date: Wed, 3 Jul 2024 14:57:12 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-mm@...ck.org, David Rientjes <rientjes@...gle.com>,
Christoph Lameter <cl@...ux.com>, Hyeonggon Yoo <42.hyeyoo@...il.com>,
Roman Gushchin <roman.gushchin@...ux.dev>, Kees Cook
<keescook@...omium.org>, Alice Ryhl <aliceryhl@...gle.com>,
Boqun Feng <boqun.feng@...il.com>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH v2] slab, rust: extend kmalloc() alignment guarantees to
remove Rust padding
On 7/3/24 2:32 PM, Matthew Wilcox wrote:
> On Wed, Jul 03, 2024 at 09:25:21AM +0200, Vlastimil Babka wrote:
>> - if (is_power_of_2(size))
>> - align = max(align, size);
>> + if (flags & SLAB_KMALLOC)
>> + align = max(align, 1U << (ffs(size) - 1));
>
> hmm ... maybe this would be faster:
>
> if (flags & SLAB_KMALLOC) {
> u32 tmp = size & (size - 1);
> align = max(align, size - tmp);
> }
>
> (if size is 2^n, tmp is 0. otherwise, tmp is size with the lowest bit
> clear, so size-tmp is the largest POT that divides size evenly)
This is used only during kmalloc caches creation time so "faster" shouldn't
really matter. What would be nice is "more obvious" and to me, neither
variant particularly is :(
Powered by blists - more mailing lists