From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B382FC3064D for ; Fri, 28 Jun 2024 09:34:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28BF26B0089; Fri, 28 Jun 2024 05:34:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 214316B00AD; Fri, 28 Jun 2024 05:34:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08DD86B00AF; Fri, 28 Jun 2024 05:34:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D94FB6B0089 for ; Fri, 28 Jun 2024 05:34:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 765231618BB for ; Fri, 28 Jun 2024 09:34:51 +0000 (UTC) X-FDA: 82279787982.14.9E8B3D3 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf13.hostedemail.com (Postfix) with ESMTP id A2DB72000E for ; Fri, 28 Jun 2024 09:34:49 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mAf3zbrz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719567269; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R5Gyzd0KEYojFlORA9Zt8V98aCcTYQ8VgOMnEXwuyS0=; b=rxRAlMG10unux47+q1W7z7ASQM7PRfot4Eqc4Xu7anwewGMj1T+0VvS+DE3DJtK9rV71xw isdSmGGD+7CbEORmICztcgqbgaZXqRv2zdaKeGkmnqE6NIViZ9BESwrk/BRXbkZHTdQv5f BHiUbwuMG2Y+MWG1RdWthNOgVZI4c6Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719567269; a=rsa-sha256; cv=none; b=BywNJIYNyvv0JjIld6wIQISh8sgwwznqJOki4L2kDG+aNrlSADeZxS9JpeL9DbiBzii9QK 6PTU3AsdCJvh6ucdSOWPgDmQDTMFtk1GwAJjxINEga/fqmxjEjdQ1BCRLscEky6dbsZ3Tw +lTJCKIYnt+FChU/XMn7KtYFTz3y9kw= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mAf3zbrz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=aliceryhl@google.com Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-424ad991c1cso4375685e9.1 for ; Fri, 28 Jun 2024 02:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719567288; x=1720172088; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=R5Gyzd0KEYojFlORA9Zt8V98aCcTYQ8VgOMnEXwuyS0=; b=mAf3zbrze/cr1CCurC8HCaEPvDUFNZMl/1DCP4HLDLQMfQBDaa06RT9EVLfOvH4aQS QApW9zbQS4jT3oATQStIspKLwJIhpaip+vlvN75yKGPjS6gcFA9gSqriLHCeD19PBoWG c5Kzuw7mNmjH26Muk6Rg6pf3fOG4k2LiypBUESEgNFRYnEzFppdf9O3xBD6TOvGZlpQk 7X/idy2YgsAGssiHcsZ3dqngcM4aSWNxUvzCFY9Ho3vO48mSokkj/R/n156nnYR8WoG0 QsqzAIHJ+X6uCVEU0bZXzwC6LwTkaPRpKuvKY5MsBaTJA9cP8XaN1RduKXatQEhRZWlV FjSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719567288; x=1720172088; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=R5Gyzd0KEYojFlORA9Zt8V98aCcTYQ8VgOMnEXwuyS0=; b=p6dis/ZmhJFJHPQk5a0qG4zvurn92k+aFvD17eEGIL4ct45pm1HXLf9yQ9B47zle9B CUlM4SYBfIr4GFd+dIGagY0q5RQt7gVyK/ZqRrcD3ctRT3cfgXttqgPun/f2ysEKimt6 Q2v7Quh+BgwTAKgE6Fshmdi4ZATzIwepmaQTx+EEG694F0O/6bfruzFDlYT1rAk12yqA 8ZJnEOqyHxAbHTH9PjxSkBIctyR4ebaqP/xoNU/BeQIByRxa2iZC2Td7SgDfWo+kQy19 np9Cgx9Bxk0bL4QPOjP8NiFGgFlnBFockK1xNQ8p8URvpuvwF5otS/qukKypdz+of2Y6 ViMg== X-Forwarded-Encrypted: i=1; AJvYcCW3i+70zZQIdSZKRl56NNfDdrKPpfOytsGqek5EeSCkrym42JwT8yVGjY8jPIEfp9FYQEfeIfwmSVFvUkAQN4Vft3U= X-Gm-Message-State: AOJu0YxW9g4j46F9YxkXOCWC6QI6z+pxzEnQM9sUv0SNvpIHCWfzXcvs 786AZYq6dWg1q+1sRkXyPrOta8K0henP+CdGnxmqfBjLlPcUGy0q2OvggmTNQBbrmyFoWoTZqt5 BBwxNMhaEWqBAAnh89s70h3gmZ/9n13R17xJq X-Google-Smtp-Source: AGHT+IHkMX5345OLYcmRT3XnelwwzbNOLPwlwqhS2DVYP+oCW1ISdTPYj99BI+fmIoO/MdYp0rp3L25a15KF4hw0UuA= X-Received: by 2002:a05:600c:1c1e:b0:425:692d:c72d with SMTP id 5b1f17b1804b1-425692dd443mr23095585e9.32.1719567287924; Fri, 28 Jun 2024 02:34:47 -0700 (PDT) MIME-Version: 1.0 References: <20240619192131.do.115-kees@kernel.org> <20240619193357.1333772-4-kees@kernel.org> <202406201147.8152CECFF@keescook> <1917c5a5-62af-4017-8cd0-80446d9f35d3@suse.cz> In-Reply-To: From: Alice Ryhl Date: Fri, 28 Jun 2024 11:34:35 +0200 Message-ID: Subject: Re: [PATCH v5 4/6] mm/slab: Introduce kmem_buckets_create() and family To: Vlastimil Babka Cc: Boqun Feng , Kees Cook , "GONG, Ruiqi" , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , jvoisin , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Xiu Jianfeng , Suren Baghdasaryan , Kent Overstreet , Jann Horn , Matteo Rizzo , Thomas Graf , Herbert Xu , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, netdev@vger.kernel.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A2DB72000E X-Stat-Signature: ppowz6rbwe9gi89atdyyez7e4n7kkhco X-Rspam-User: X-HE-Tag: 1719567289-540979 X-HE-Meta: U2FsdGVkX1+4PpW7wt1es6sP1RJilmkjk4w+FCQprF2mU59qg7jfKYLF/tUhRRDCVoom67YE9BnYsWZmo7+HFh9JCNds5C97PGfsS4h4FfjuxC0zki4TTE3ieg3rXdMJ+tXW/gAJuuhlQcHcuZBOqzjm5d23bOTmc/Yh0LnR3YwOa6PiK0cEq+nH6QB+fHpaOOD5ozrDsCVJ2AIWtOKD+D6YLMNwIWd20lJkoHo5ton/OX6ZwqLXC6Up549wYhRTq+EEx7S6mROIyAWXM/kawXow9rgCM2/NIKXXCQbDRdboNjLK6CHIs/7qeRpIBUvZEB5C7ca+pRq9ncvnrE22w/4jVgHLnHSJM+Z2bCdxv/Asx5dVIZiuh/y6Ti5UinbINV2l5EgXChWKdO3U36iC14awyg8h93elGqPziK+qTtzNrGrTJW0X7hM3cuzS5C8y95Hb4vVQMwWnybdK28qDStAGIePvZRYxZiAxxolPRX3mdWHylvaVFNUnZ+rsnntabnA9pvqdQxub1nU7XKiWu6KY9kSAJc+3ncsLa8PZqYlsXIS/SAaNfSuXdTnwNPZY0QglRd+c0Br/PbDGBJwSn+gq9rxABPsSaHkgYb8kWQeDS7YQb7/YKFH5siyNs0iWdAK0+j7lAxEhfHEkIs6E3alwXhIB9wG2XifKM1+aecj8Sb4n1OL1gTppZDdZ97GLVv285eo3yyQ3LVZ/DqJz6EYkom7JoH0tE8ryZplIJEySo2npe5RKBiaRhwMPp3CFdrA2Iq3udU6hWrUrZJUhbUrLpdannByOnzqHAeG2k7eQkLyQWRy2auvRikEsb2UeHauESVAAxOKUg6OKp9qICgwLx3rlS+rNdtR3F8qFLLUzchCRIkjV3sgSwOADxmE7UUEWePmR3hc7N2LmZtrLWLA99K6yz23g7ZGl3zKzCBUcnxVgDGMHrF2QFVuT3BUkOQtnuS3ea4GYgj7h/jl giexirzZ 0LjUmpFfoobWFXrf8ifnDpu2/Z4ZW6TEKvhm0H5IeumK2wMmKivUg3Y8ztzmvIvMpAYvaSA2qpcZiuCOQaDHfQbfBnKA8oM4JWXqi44WQz1LsgBnpLhyWn10ILvlCzcmsY5DhHauQgebgcfYTwO7IJdxAR2Dr09lPm/4QvRTLP1utLRuGUBS+/xzRzaaMe/wyi5ehEDjll8tI7+XD/ga+laIFtglQ2Dch6bilY8JQ8+L5W8X6sT9l5fz6ZAIUWnP+3HcoWmC5ntVF1bKQhcbSvsbFvzIp6NHIkPojz6fJbYnrj/DF/t2JHeTJ2xStTpk3pZxeH0EdBUVPl/qP9lY5hX/745Iukt20wt/m59zz9PQYRp57m99/aOJV5hCARlwFrocq+0sycGlyiAm6Kw28lPc0kA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 28, 2024 at 11:17=E2=80=AFAM Vlastimil Babka w= rote: > > 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 al= ign > >> > 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 obj= ect > >> > 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 t= hose > >> 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 a= nd > >> 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 crea= tion > >> 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 si= de > you would only have to round up sizes to the next multiples of the aligne= mnt > (rule 3 above) and that would be sufficient? > Abstracting from the specific sizes of 96 and 192, the guarantee on kmal= loc > 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. If kmalloc/krealloc guarantee that an allocation is aligned according to the largest power-of-two divisor of the size, then the Rust allocator would definitely be simplified as we would not longer need this part: if layout.align() > bindings::ARCH_SLAB_MINALIGN { // The alignment requirement exceeds the slab guarantee, thus try to enlarge the size // to use the "power-of-two" size/alignment guarantee (see comments in `kmalloc()` for // more information). // // Note that `layout.size()` (after padding) is guaranteed to be a multiple of // `layout.align()`, so `next_power_of_two` gives enough alignment guarantee. size =3D size.next_power_of_two(); } We would only need to keep the part that rounds up the size to a multiple of the alignment. Alice