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 21FADC8302F for ; Tue, 1 Jul 2025 10:34:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAEDB8D0002; Tue, 1 Jul 2025 06:34:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5FE18D0001; Tue, 1 Jul 2025 06:34:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4E4A8D0002; Tue, 1 Jul 2025 06:34:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8F6628D0001 for ; Tue, 1 Jul 2025 06:34:22 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3E7D11A03A1 for ; Tue, 1 Jul 2025 10:34:22 +0000 (UTC) X-FDA: 83615336364.29.79C1A11 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) by imf30.hostedemail.com (Postfix) with ESMTP id 64E3B80006 for ; Tue, 1 Jul 2025 10:34:20 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WEevpu8N; spf=pass (imf30.hostedemail.com: domain of 3qrljaAkKCPUXifZboveidlldib.Zljifkru-jjhsXZh.lod@flex--aliceryhl.bounces.google.com designates 209.85.221.73 as permitted sender) smtp.mailfrom=3qrljaAkKCPUXifZboveidlldib.Zljifkru-jjhsXZh.lod@flex--aliceryhl.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751366060; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9eYpIWWOyUDfBdnF6w5EzWxG6nDSQGMmFCg+4mWFSaM=; b=sgjvGskUtbziLfdx27QYyq5PE4alGEzPnBF1ITD4ajl1NWWhVbBtWl8JCT1hFW+ppL7qu4 3lF1pj8fvC26Hmrw/CQBpvFqw1guUarh9zzmcNXACu56Z5lT4bnEAuxGo3jtNSFICjpAi1 ENUgVfyo08vhFbTeCcKEqVV5U8ZQFXw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751366060; a=rsa-sha256; cv=none; b=2CcRtCW2f/qQL3icSARu5GdkWvlSTAixu637enBID0RkuKjNZarTM11WDPxb3ncEWEaOFE r/UXevZ30nr+XQAUYv+7ZTQ3wHhR4VogGypxDiVPj/GayB2gbpb4DcsLgFEAq2/KIHG0z8 Wns6iPdw7x1mo4DMIlfGBoTIOgwAJNE= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=WEevpu8N; spf=pass (imf30.hostedemail.com: domain of 3qrljaAkKCPUXifZboveidlldib.Zljifkru-jjhsXZh.lod@flex--aliceryhl.bounces.google.com designates 209.85.221.73 as permitted sender) smtp.mailfrom=3qrljaAkKCPUXifZboveidlldib.Zljifkru-jjhsXZh.lod@flex--aliceryhl.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-3a50816cc58so2825967f8f.3 for ; Tue, 01 Jul 2025 03:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1751366059; x=1751970859; darn=kvack.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=9eYpIWWOyUDfBdnF6w5EzWxG6nDSQGMmFCg+4mWFSaM=; b=WEevpu8NklpPsgN/evQk4FvkwgsWO8F5YCY0UtVPsbhOu0AHP/ZuZmHoOCuKJZkYts o+/30Fg6S3/pBfhxsA2S6osASBZsDc8FCA2ITSDtMMxDwwUoZhAaAwGnFU6V2nbhWlh7 q0b0tcznkQkQ7LOyY2/T2OQXl4h5JG3Z99O4LjD0vvGcKhMpeN53DkEQ+pJXrmK36OZZ Sf44oYlQnwxPzd1fx79p1phmlwALU2PBs7NBbYU7hNz1zDnr9a3iMA2EymLaBUihu3XY xsc++Y8zO8NZHHVzzAheMU+kdUdRIu6io2HaNmaGCu4WH+d7OGJ+H2Tdt7eLrHnfdQ2h kNiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751366059; x=1751970859; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9eYpIWWOyUDfBdnF6w5EzWxG6nDSQGMmFCg+4mWFSaM=; b=eG1XpsWTaeS+VLtEqvO7Zncls9baGiv8kbNdrg16iPv7z7GVmklhE4WoHTqCB2VLqc WEiH/3W/ZGLTl50b/cUMUs6ejuYxAHoE6D7IMogRmEaaX7fLozR3NQ5XVmlTA72EGYcU 6zKAG28/YymbSL0OLDMmvDBNT4/E2qU0Se+9ukmRb0t8fiuekZibcC44ujsb1tB26MWD C71LWXxWC/0Bnn9+y2M6XxrLe48Oh4oYmNErMTim7JbiVrG3hsWW0bYuSn9SxkLDb5XR F5RInlPBoA49dJ/MoBjlYlALJboIbPcJccYfn2eN6HSgM6fPC7KKCpiw/b7WS/31+ind ksYw== X-Gm-Message-State: AOJu0YyPrRULTUsCJQ2H1HcNdiaK6Gt4nVQNi/BE49dQvKfUzk3YzGz2 eZ+uAxRsrAc85Y48V9TWUtt4cCb/GksIuW5+mQvHowMjGcitJDPaUh8hnDlCGHuvUtMnqZ7GVXw hpbkoKSaUXMdrS7rHRg== X-Google-Smtp-Source: AGHT+IExCFB+P+olVhWi69uc4CgDaEnI8SE94UUo0CxDvKCx5CZn1RoH+3jT8lmx3jEG2VJ7mPnAhF7D8TcmUIk= X-Received: from wmbds13.prod.google.com ([2002:a05:600c:628d:b0:450:da87:cebb]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:646:b0:3a5:8600:7cff with SMTP id ffacd0b85a97d-3a8fdb2a82fmr15767911f8f.1.1751366058480; Tue, 01 Jul 2025 03:34:18 -0700 (PDT) Date: Tue, 1 Jul 2025 10:34:17 +0000 In-Reply-To: <20250630221640.3325306-1-vitaly.wool@konsulko.se> Mime-Version: 1.0 References: <20250630221511.3325123-1-vitaly.wool@konsulko.se> <20250630221640.3325306-1-vitaly.wool@konsulko.se> Message-ID: Subject: Re: [PATCH v9 3/4] rust: add support for NUMA ids in allocations From: Alice Ryhl To: Vitaly Wool Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Danilo Krummrich , rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="utf-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 64E3B80006 X-Stat-Signature: k9tmjqiidsjkzhkirknfiwx1iu3ma7do X-Rspam-User: X-HE-Tag: 1751366060-349256 X-HE-Meta: U2FsdGVkX19pACBoc89lQBzKj6GHMB5jiPYNnklR/QUlmAvmM9lqTFSBHWSqqKCPr1DeA09JSH1UZIAPboaYTi1zVBk9ow6hlaXadCEnjcgv1llwSCE02DqZ//eyCBzJ+8UKOQJ+uPaQflf3DB1CwHk6CsXlSADdpUIAVvW1RPBb4txuarRnhlc6JR2TpuMRb9s3h3fLILCkuyhROAe4P3EHUO95U836lncSY8mH7ryPCEAjbaA5/3howeqFQ6hA7RVFgg4hbNUs1W/bhkAq+qhnheUW03ZwtXAcLjiA4cJj1M5SnO/Sv5Bt4Vhn77EC433nF7nU7HGMRnmS7yLwxasA9OhODUZ1wcBKeudS+Op1+0YGnZGlvBGMQsE1XmpSScE5iiRo4XnzOx1CGqvgXBiPnVfCMiMDY5GoGkK1qiJ9rEao3+BEzr4t7fc7jwAFzH//VL4aTdGayDXvdyiuGy7I0SpM+cVoSe7HHHxVb39nnvJfx60IQaGpDKQTsUqKIuVd5/qNHZke7/ZA139/Ju1B6gOUvdJe8eB3dhYb7tpimanlNmvI8Auv1p+fKaL61WrphWMwEdl1Pfu2VTFUzwuy+d71jk3OkpiWmXs3CrmQBDLuL72NwIRSUaJxd3512dG0lbpjOtYWFZn0kcoZayQZ7kxTj9zyZc9bsJ9Wu2eUUFNJ6HJd5VsIstFo7mdKKxAxNBSgg4ss6+27zzFTn/RUruCO7jZYUAfJNAtncEZSxEhOuBd8/fOZGSfzNLtBT75a31UEPLXCeYJkr4ECta2ht9qRhxzpgJdMABMfFo+Uqa7IF5YHl5CerW7+SPuj7PArrl8xmRU98pGcKJTwfeDkrgYq2IQ91svrSTDT3dEBYKiT21hjd4WLNOvRuVASFzilz30kpc5yCJ7rXhgPN+eYXW7kqQM3J745DM231P2xcsjBBPd0R75kvbYP+rvVcpbHM0Vm3QSv9LARHeB w/F4Z6Mq P4jcrRmZso8YKBzMBoqLBaVijpl0ZL69CuvzRW/ajVQ2Xg9h7caQLwO1AXHEBNkeeYScaX8SD44incI+rpiQUettxgEkFWMSsoN7VtxNyichZz1TbQuki00I7Ok7STa2tmjo3ekbeAoVkkKfUzH7aerDS6cUES3bubz+fRVbe1VXhRHx7gUVs7V8uY6YmoDuxFUNg7UarHaOxcbNHF+wHpcHTwGDpGwQSQUPmsh8fpvUO+7Ebmf0jekDWgVevzaoIE4shQLk4TqlM7wgUYxe2vLFj2BE8PvAUHxS7m/vBY4UrP4glGYvSJ0XbqCG7d1T3elQJVqtuejXUezVXRpbDjsGDn/ef0lnW2/oNgmFTRMxqZihTLufNaCJP4HYNkIFiYaDA/OF7JJLw3sNwqzfyNmO5TzQzA1iscDPS83jm//9UEtM1XYKYVfjmPbYqsVihHuG8Dsltg9duwfUCOE0oX0sMrYLeXJsLNZ6WICmXpzW5ZOegJwFKK7O/sL6U2hRoXAn2Omc2bXb29VYDKRaPur9LVtuHmTlQAuOKEnOQrm10spAIfvxOuAEHsJxy76xMsjMNf4ar0SKjJKsM3g2YBfqfD27eorZIUR8Dm+2v0ELxfrXzPtft4V+8V6+7McxV4tQjcQVWgMBY9Z+qgxGhIocYyA== 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 Tue, Jul 01, 2025 at 12:16:40AM +0200, Vitaly Wool wrote: > Add a new type to support specifying NUMA identifiers in Rust > allocators and extend the allocators to have NUMA id as a > parameter. Thus, modify ReallocFunc to use the new extended realloc > primitives from the C side of the kernel (i. e. > k[v]realloc_node_align/vrealloc_node_align) and add the new function > alloc_node to the Allocator trait while keeping the existing one > (alloc) for backward compatibility. > > This will allow to specify node to use for allocation of e. g. > {KV}Box, as well as for future NUMA aware users of the API. > > Signed-off-by: Vitaly Wool My main feedback is that we should consider introducing a new trait instead of modifying Allocator. What we could do is have a NodeAllocator trait that is a super-trait of Allocator and has additional methods with a node parameter. A sketch: pub unsafe trait NodeAllocator: Allocator { fn alloc_node(layout: Layout, flags: Flags, nid: NumaNode) -> Result, AllocError>; unsafe fn realloc_node( ptr: Option>, layout: Layout, old_layout: Layout, flags: Flags, nid: NumaNode, ) -> Result, AllocError>; } By doing this, it's possible to have allocators that do not support specifying the numa node which only implement Allocator, and to have other allocators that implement both Allocator and NumaAllocator where you are able to specify the node. If all allocators in the kernel support numa nodes, then you can ignore this. > +/// Non Uniform Memory Access (NUMA) node identifier > +#[derive(Clone, Copy, PartialEq)] > +pub struct NumaNode(i32); > + > +impl NumaNode { > + /// create a new NUMA node identifer (non-negative integer) > + /// returns EINVAL if a negative id or an id exceeding MAX_NUMNODES is specified > + pub fn new(node: i32) -> Result { > + // SAFETY: MAX_NUMNODES never exceeds 2**10 because NODES_SHIFT is 0..10 > + if node < 0 || node >= bindings::MAX_NUMNODES as i32 { > + return Err(EINVAL); > + } > + Ok(Self(node)) > + } > +} > + > +/// Specify necessary constant to pass the information to Allocator that the caller doesn't care > +/// about the NUMA node to allocate memory from. > +pub mod numa { > + use super::NumaNode; > + > + /// No preference for NUMA node > + pub const NUMA_NO_NODE: NumaNode = NumaNode(bindings::NUMA_NO_NODE); > +} Instead of using a module, you can make it an associated constant of the struct. impl NumaNode { pub const NO_NODE: NumaNode = NumaNode(bindings::NUMA_NO_NODE); } This way you can access the constant as NumaNode::NO_NODE. > /// The kernel's [`Allocator`] trait. > /// > /// An implementation of [`Allocator`] can allocate, re-allocate and free memory buffers described > @@ -148,7 +175,7 @@ pub unsafe trait Allocator { > /// > /// When the return value is `Ok(ptr)`, then `ptr` is > /// - valid for reads and writes for `layout.size()` bytes, until it is passed to > - /// [`Allocator::free`] or [`Allocator::realloc`], > + /// [`Allocator::free`], [`Allocator::realloc`] or [`Allocator::realloc_node`], > /// - aligned to `layout.align()`, > /// > /// Additionally, `Flags` are honored as documented in > @@ -159,7 +186,38 @@ fn alloc(layout: Layout, flags: Flags) -> Result, AllocError> { > unsafe { Self::realloc(None, layout, Layout::new::<()>(), flags) } > } > > - /// Re-allocate an existing memory allocation to satisfy the requested `layout`. > + /// Allocate memory based on `layout`, `flags` and `nid`. > + /// > + /// On success, returns a buffer represented as `NonNull<[u8]>` that satisfies the layout > + /// constraints (i.e. minimum size and alignment as specified by `layout`). > + /// > + /// This function is equivalent to `realloc_node` when called with `None`. > + /// > + /// # Guarantees > + /// > + /// When the return value is `Ok(ptr)`, then `ptr` is > + /// - valid for reads and writes for `layout.size()` bytes, until it is passed to > + /// [`Allocator::free`], [`Allocator::realloc`] or [`Allocator::realloc_node`], > + /// - aligned to `layout.align()`, > + /// > + /// Additionally, `Flags` are honored as documented in > + /// . > + fn alloc_node(layout: Layout, flags: Flags, nid: NumaNode) > + -> Result, AllocError> { I don't think this is how rustfmt would format this. Can you run rustfmt on your patch? Alice