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 E9D22C77B7C for ; Wed, 25 Jun 2025 20:29:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42FFD6B00C2; Wed, 25 Jun 2025 16:29:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 407B66B00C4; Wed, 25 Jun 2025 16:29:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3446B6B00C5; Wed, 25 Jun 2025 16:29:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 24DBC6B00C2 for ; Wed, 25 Jun 2025 16:29:22 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B37FA121F12 for ; Wed, 25 Jun 2025 20:29:21 +0000 (UTC) X-FDA: 83595062922.17.E3F4F42 Received: from mailrelay6-3.pub.mailoutpod3-cph3.one.com (mailrelay6-3.pub.mailoutpod3-cph3.one.com [46.30.212.11]) by imf02.hostedemail.com (Postfix) with ESMTP id 27FC88000A for ; Wed, 25 Jun 2025 20:29:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=xlWYxEIt; dkim=pass header.d=konsulko.se header.s=ed1 header.b=e1VP2Tqq; spf=none (imf02.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.11) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750883359; 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=mFicMW97oCaFX3ytmFZghvLQmZgDqR8OgB6iTx+baCA=; b=vb2zN8gCCBPdiqzf4esZ5697d39TQiBqwOzD+uKVhwSRwWkBrBdLr2oSg+9rDrkfyDxfyj u/yIqXqdkrCorsNUQVujK2BBVmdXRldNrSHPeevpscbdhN97VPtLeOcTnA2hUmGHR+vnCe w9FEW0GoQo+9V1wEdvy4A8E0wuWMLhA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750883359; a=rsa-sha256; cv=none; b=V2xjgY/aTJkHJuHGvK0p3YsGc0KD6czl38Sln0AKE6kYSTTFMml+z/rHAWaJe3sAjjnIym n9e6CulAvwy3DiYsOwj/Za8ZV/omjx+M/fqhP7FRZcuzcsth3sD94+NUq5lp7zUmtD9fXp lnVPq0FEeSMTVqeAGMLogJc8V3K5xFI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=xlWYxEIt; dkim=pass header.d=konsulko.se header.s=ed1 header.b=e1VP2Tqq; spf=none (imf02.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.11) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1750883356; x=1751488156; d=konsulko.se; s=rsa1; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:from; bh=mFicMW97oCaFX3ytmFZghvLQmZgDqR8OgB6iTx+baCA=; b=xlWYxEIt96EYtxtxqfAkDKuAn42RhF4BXnMhnbDT4tX9n8AZs/S7PBTGJHkJtZWCDOwujMmd8Hvpx uA+V1ub2XXvaGc68ADH67NAcIJJ8JI8+Jqq0WwwJ1b9mMR+p9g2jb7Wsc3BqFmdRtUEFVGcYSjRVKI kn3pTyP6IM96YqO9zGtHY/2Al0BBJoHSpXDlZD8nyIpP3flgxtOdLsrwRjfe+2gES0gI7faSJJ5ud0 fPo6ZBy4GifEPHmRBAiyg8DicoqJW3k7ovWISrZAM0sdNUe0kp+so0+inW71+UBy3jB2dv3nbWStNw 5ru0KiBrS8KyqjQc+6phNWvVRrUTHBg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1750883356; x=1751488156; d=konsulko.se; s=ed1; h=to:references:message-id:content-transfer-encoding:cc:date:in-reply-to:from: subject:mime-version:content-type:from; bh=mFicMW97oCaFX3ytmFZghvLQmZgDqR8OgB6iTx+baCA=; b=e1VP2TqqOq6P+uUeLxOSceSYWSkdKhkMQ7NYvr4vQ2yjSIBjR4EMk8hv2ppLiDME9rAD+XXA5HRFg UmXUSZqDQ== X-HalOne-ID: 0f22a303-5203-11f0-843b-417246ffdc90 Received: from smtpclient.apple (c188-150-224-8.bredband.tele2.se [188.150.224.8]) by mailrelay6.pub.mailoutpod3-cph3.one.com (Halon) with ESMTPSA id 0f22a303-5203-11f0-843b-417246ffdc90; Wed, 25 Jun 2025 20:29:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.200.121\)) Subject: Re: [PATCH v3 2/2] rust: support align and NUMA id in allocations From: Vitaly Wool In-Reply-To: Date: Wed, 25 Jun 2025 22:22:36 +0200 Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Alice Ryhl , rust-for-linux@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20250625062917.3379804-1-vitaly.wool@konsulko.se> <20250625063026.3379921-1-vitaly.wool@konsulko.se> To: Danilo Krummrich X-Mailer: Apple Mail (2.3826.200.121) X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 27FC88000A X-Stat-Signature: un6omymxrsapzty1jqcn4qngfnbezmru X-Rspam-User: X-HE-Tag: 1750883358-884337 X-HE-Meta: U2FsdGVkX19qYsJCxqmi75NjjElvt89YJATZ6jSX7l9fhJoymCcmkoOxkyAlMr3iDvwruXVov6zlq4JWIZ56PklKlGMyqs23hg/ae6aMrxybXxScyedY1GRpJAVGNilUgdscbuTtF5Lyqi+FeoRCHzkRAsF3okv4dOTUUerZUdGSgl9gmteNJU1By6w5TuBmcppPRVySUhM2P8gczilaLAqOIfZxIe3WvXT/wBXSQ28mi4uoriz8V+Vo1WLZ/4x6MWQobPYw/ajvda96gSKvnwNaAvDtRx28dpbew6O6Qnhs1nbv0t9yeb9M6IUOlPXG8I9A36QyzOFUUfM1aD9taQVlZEJ9GwWBf2REOCmywA6c/bYsaLnSWn537TknJ8hnAAPlxtTqd4wfquekoxVO3F3wvufSG0gVKFuUaYvh+KFzdT7IA1ER0jMlqSdHo7p86mcutm7Q5LH23+W4jR7S2OqvUY52VmpElqy4w93YlgvN8yWJJ4/fNfGhLau2WlL74kppyhTDQJSptVkrNtqwdcboUY8htE5FwtRf1teDNhs+PZwg5J8j/PHqgfegB4nZmDA3Q6oTPNH1M44RfAWiKjPKyeOU+eNZ69NTjzUN1uEAyxpmRSzzcFkg84mvLm58OhCq9h3ygp2nCQuQkQKlEwOq59V2KMOGPaRfPXDWDbCNUhqeXlge2/TuWgq9Juh8DyLCpadusNRwTJHwbrhdhaqtjTbYXOBVkAVoDbCFtEzEpoPJtHkCo0cwTrtKArXcDqe1a/PcJxMwwfSqZQ7QuFCm3cGPAOGtS4K4hZ/XR/Lx0eXHjLwmxTpaDtGzYiRxw2q8o4GAVbtE5K6SJEIUWaW9tLgndtGe0KrbRd3TB9mqp6290WQ2OxtebQdXZv+KQmJpKef/3NapkiAg35M+dC72jiipayAAVJf5L9YihjySyPKVT3EkUPDSnacSM56ZHefExiWWsYmRoGE/+lc YL0SzJwB /pHEDOnjip8jQj4Dy0ybX3TsGSSpvq8k5NdjUhusrhIObmJSJVRz56iRvas8BZcZgZnvjWZvvC0YN/ZQDR0O2hqXDR+AiSlo7TFsf1YrAmvNyz241q5BvQbCnMzNwXh1EGE5g6vzgyIKPZvzUeKPEMWkeMQZSV8b2XUWZ3iyK4pyv5ttLewBADBlEWZxilV+ACWyqsYcyaIvS5X/V3hChGoQFXq47JVAkfIcZzkavgMZWCFXzyHn62wxI7Qo2YXUScFmR8itPK7fIbHc= 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 Jun 25, 2025, at 9:07=E2=80=AFPM, Danilo Krummrich = wrote: >=20 > On Wed, Jun 25, 2025 at 08:56:05PM +0200, Danilo Krummrich wrote: >> On Wed, Jun 25, 2025 at 08:30:26AM +0200, Vitaly Wool wrote: >>> Add support for large (> PAGE_SIZE) alignments in Rust allocators >>> (Kmalloc support for large alignments is limited to the requested >>> size, which is a reasonable limitation anyway). >>=20 >> Please split this.. >>=20 >>> Besides, add support for NUMA id to Vmalloc. >>=20 >> and this into separate patches. >>=20 >> Please also add some information to the commit message what you need = node >> support for. Do you also have patches to add node support to Box and = Vec? No, but there is a zswap backend implementation written in Rust and it = should be NUMA id aware. I=E2=80=99m planning on submitting that basically as soon as this piece = gets accepted. >>=20 >>>=20 >>> Signed-off-by: Vitaly Wool >>> --- >>> rust/helpers/slab.c | 8 +++++-- >>> rust/helpers/vmalloc.c | 4 ++-- >>> rust/kernel/alloc.rs | 28 ++++++++++++++++++++++-- >>> rust/kernel/alloc/allocator.rs | 40 = +++++++++++++++++++--------------- >>> rust/kernel/alloc/kvec.rs | 3 ++- >>> 5 files changed, 59 insertions(+), 24 deletions(-) >>>=20 >>> diff --git a/rust/helpers/slab.c b/rust/helpers/slab.c >>> index a842bfbddcba..221c517f57a1 100644 >>> --- a/rust/helpers/slab.c >>> +++ b/rust/helpers/slab.c >>> @@ -3,13 +3,17 @@ >>> #include >>>=20 >>> void * __must_check __realloc_size(2) >>> -rust_helper_krealloc(const void *objp, size_t new_size, gfp_t = flags) >>> +rust_helper_krealloc(const void *objp, size_t new_size, unsigned = long align, gfp_t flags, int nid) >>=20 >> This should have a comment making it obvious why the function has two = arguments >> that are discarded. I think we should even separate it with an = additional inline >> function. >>=20 >> I do agree with discarding the align argument, given that it's not = exposed to >> users though the Allocator API. >=20 > What I meant is that proper alignment is implied when krealloc() = succeeds. I agree, I need to add some comments explaining this. >=20 >> I do disagree with discarding the nid argument though, since you = change the >> generic Allocator::realloc() API to take a node argument, which for = KREALLOC and >> KVREALLOC is silently discarded. If we introduce it, we should do so = for all >> three allocators. >>=20 >>> { >>> + if (WARN_ON(new_size & (align - 1))) >>> + return NULL; >>=20 >> I don't think we should have this WARN_ON(). If we want to warn about = this, we >> should already do so on the Rust side. The helper functions in this = file should >> not contain any logic. Agreed. >>=20 >>> return krealloc(objp, new_size, flags); >>> } >>>=20 >>> void * __must_check __realloc_size(2) >>> -rust_helper_kvrealloc(const void *p, size_t size, gfp_t flags) >>> +rust_helper_kvrealloc(const void *p, size_t size, unsigned long = align, gfp_t flags, int nid) >>> { >>> + if (WARN_ON(size & (align - 1))) >>> + return NULL; >>> return kvrealloc(p, size, flags); >>> } >>=20 >> Same as above. >=20 > This is actually different though, here kvrealloc() may succeed even = if the > requested alignment is not fulfilled, so this is incorrect. I can move this logic to the Rust part, too. My point here is, for = Kvrealloc with a large alignment we=E2=80=99ll just make the decision to = use vmalloc, period. We can indeed do that on the Rust side. ~Vitaly