From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AECB4152530 for ; Fri, 28 Jun 2024 09:34:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719567291; cv=none; b=I0feA0XuXzS/j1jYvK96VW8UrzzyhXKlzy15I9e3ynmo+8WTyv2NE36tpB1/VGG+QWl83dyDakmA3E3xxKXiQsm4qEvb4/hzjNi3n6fucZuWdpkhxaRUTLQY9KBKwnTM+Je0n26JbtEZS7WcWd3nKIyohHHcS7gel6A66SZ69/A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1719567291; c=relaxed/simple; bh=mVgpkGZeEUIJG9UJ4SJVmxmneMeKnT/4EHHpcMGGZ2U=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=er6TGkSZuh+w3u5cV2QK3lBB/ullegXhFW1ErygpWpymrmrZpd8v0Dc/wsTNJ+1Tsj88OHgWdi7cNGN8AXiK6+alYNnDvb7Rsa2fWJwXdH6u/QaPvMv2AZvCWjWtGQXR6pzuUdmqNx2910KZKpMvvOFuyePQ0YmOALbBKU+RXao= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=0jEGxzm9; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="0jEGxzm9" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-424acfff613so4484785e9.0 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=vger.kernel.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=0jEGxzm9bjV7qzwpsbLi/sY/bku21UXzhP846PPiz3H7hFYF4Q/cErPNFDbeJmGcbW RzeySL5v8Q/vBMEAB8IQe6Oy7Wm7K6hwHewCnUBeRVbxQwEGzK8rE76ztohLnOmlQYqc g5dY7JdMaZsMrJESPO+MhLQ8HDr9C4DSani1tsHd2PSxsvzgnXEPKcb1EwSCuDco6qmH HWT/R2Yjn+fTIK47svur0u+p1G8xgJq8y0YroZVtrNGLYukVoX9Wi+uQKV0OomaVDM6u yb98FQP9rZ54aoRIv0tn1YFWp1dDQhEZba1Gry3Wss1f6oBNJUOeck4JiuhZbP2KRzKU wUQw== 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=b1vrL7kaA9jim3V0WF8SinxOsgY5OImeYdcHGqRZEv+7GsTRBn5X8mfOCdP9eIWXMu BhR61CHCd9M9mv4h7l6NcLCfjcaTwHA4r6A0f4/grmVLlrf6GroWL9cey2t+K+P+BbaE yybgQZ14vJH6psk7dNUVEZImu+BCkrbsGG55JJJRXi2NrU9JhKMf3wymNWohuUL1t3/2 7kIX2b3wkS48+3Uh0dqxxTNPOJF72iobmENHC+wsKxZaGNvM35CjPc+mXgZttPzZa5lu TEMVzMdgVk/DGbpXwaTgJo5FMrCkFlnEcqw78+O1DmYxPT1oJ8VfJM75nNFtV/6Qa9DP gYuw== X-Forwarded-Encrypted: i=1; AJvYcCXwkhlt6J/xfe48LXHNCnixmyhN2HQ8K7/xROAn4nminhn3XfWdGFIJrMU//GswNdXCoC/71ynvCx+Bbt/8PJ8lOuuFSG4tP1X7ce1ofAY= X-Gm-Message-State: AOJu0YzOtxo4HepPiFUCH4Jyt18ow8vAEsUB+1+xYghG+yP+nVT9sXMf FyloPpIXrqkoQfiCIwOH/3TA1ftcxmanMV09jGXM9walkCXhDfwLpqTDXDs8TnTddfB7d/Bxsf2 s268EyqTFVp1aVEGif8wKmGvmz9cSlx4/K58g 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) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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