From: Vlastimil Babka <vbabka@suse.cz>
To: Alice Ryhl <aliceryhl@google.com>
Cc: Boqun Feng <boqun.feng@gmail.com>, Kees Cook <kees@kernel.org>,
"GONG, Ruiqi" <gongruiqi@huaweicloud.com>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
jvoisin <julien.voisin@dustri.org>,
Andrew Morton <akpm@linux-foundation.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Hyeonggon Yoo <42.hyeyoo@gmail.com>,
Xiu Jianfeng <xiujianfeng@huawei.com>,
Suren Baghdasaryan <surenb@google.com>,
Kent Overstreet <kent.overstreet@linux.dev>,
Jann Horn <jannh@google.com>,
Matteo Rizzo <matteorizzo@google.com>,
Thomas Graf <tgraf@suug.ch>,
Herbert Xu <herbert@gondor.apana.org.au>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-hardening@vger.kernel.org, netdev@vger.kernel.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family
Date: Fri, 28 Jun 2024 11:17:15 +0200 [thread overview]
Message-ID: <c45eb0c9-21b9-4e29-a9d8-f3044c77822e@suse.cz> (raw)
In-Reply-To: <CAH5fLggjrbdUuT-H-5vbQfMazjRDpp2+k3=YhPyS17ezEqxwcw@mail.gmail.com>
On 6/28/24 11:06 AM, Alice Ryhl wrote:
>> >>
>> >
>> > I took a quick look as what kmem_buckets is, and seems to me that align
>> > doesn't make sense here (and probably not useful in Rust as well)
>> > because a kmem_buckets is a set of kmem_caches, each has its own object
>> > size, making them share the same alignment is probably not what you
>> > want. But I could be missing something.
>>
>> How flexible do you need those alignments to be? Besides the power-of-two
>> guarantees, we currently have only two odd sizes with 96 and 192. If those
>> were guaranteed to be aligned 32 bytes, would that be sufficient? Also do
>> you ever allocate anything smaller than 32 bytes then?
>>
>> To summarize, if Rust's requirements can be summarized by some rules and
>> it's not completely ad-hoc per-allocation alignment requirement (or if it
>> is, does it have an upper bound?) we could perhaps figure out the creation
>> of rust-specific kmem_buckets to give it what's needed?
>
> Rust's allocator API can take any size and alignment as long as:
>
> 1. The alignment is a power of two.
> 2. The size is non-zero.
> 3. When you round up the size to the next multiple of the alignment,
> then it must not overflow the signed type isize / ssize_t.
>
> What happens right now is that when Rust wants an allocation with a
> higher alignment than ARCH_SLAB_MINALIGN, then it will increase size
> until it becomes a power of two so that the power-of-two guarantee
> gives a properly aligned allocation.
So am I correct thinking that, if the cache of size 96 bytes guaranteed a
32byte alignment, and 192 bytes guaranteed 64byte alignment, and the rest of
sizes with the already guaranteed power-of-two alignment, then on rust side
you would only have to round up sizes to the next multiples of the alignemnt
(rule 3 above) and that would be sufficient?
Abstracting from the specific sizes of 96 and 192, the guarantee on kmalloc
side would have to be - guarantee alignment to the largest power-of-two
divisor of the size. Does that sound right?
Then I think we could have some flag for kmem_buckets creation that would do
the right thing.
> Alice
next prev parent reply other threads:[~2024-06-28 9:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240619192131.do.115-kees@kernel.org>
[not found] ` <20240619193357.1333772-4-kees@kernel.org>
[not found] ` <cc301463-da43-4991-b001-d92521384253@suse.cz>
[not found] ` <202406201147.8152CECFF@keescook>
2024-06-20 20:43 ` [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family Vlastimil Babka
2024-06-28 5:35 ` Boqun Feng
2024-06-28 8:40 ` Vlastimil Babka
2024-06-28 9:06 ` Alice Ryhl
2024-06-28 9:17 ` Vlastimil Babka [this message]
2024-06-28 9:34 ` Alice Ryhl
2024-06-28 15:47 ` Kees Cook
2024-06-28 16:53 ` Vlastimil Babka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c45eb0c9-21b9-4e29-a9d8-f3044c77822e@suse.cz \
--to=vbabka@suse.cz \
--cc=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=aliceryhl@google.com \
--cc=boqun.feng@gmail.com \
--cc=cl@linux.com \
--cc=gongruiqi@huaweicloud.com \
--cc=herbert@gondor.apana.org.au \
--cc=iamjoonsoo.kim@lge.com \
--cc=jannh@google.com \
--cc=julien.voisin@dustri.org \
--cc=kees@kernel.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matteorizzo@google.com \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tgraf@suug.ch \
--cc=xiujianfeng@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).