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 D710AC54ED1 for ; Sat, 28 Jun 2025 15:33:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 572886B009C; Sat, 28 Jun 2025 11:33:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FBD06B009E; Sat, 28 Jun 2025 11:33:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4120A6B009F; Sat, 28 Jun 2025 11:33:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2E3236B009C for ; Sat, 28 Jun 2025 11:33:42 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BB520122F56 for ; Sat, 28 Jun 2025 15:33:41 +0000 (UTC) X-FDA: 83605204242.04.0413166 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf21.hostedemail.com (Postfix) with ESMTP id 0468B1C0006 for ; Sat, 28 Jun 2025 15:33:39 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JP3SfskJ; spf=pass (imf21.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751124820; 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=P4IgVi60DFTm05ChJUdXe/2jCIBmnyX05YaAV64RYiE=; b=5snG3dzL1szQtz8P5T7v8o8d1f1hoTqjjUVibsZLt3cXG6NrK18C4BUouVNpYr9Xz0Qgsi 4znGnQA6szLb6++dr9ya0rsU7/e8M/aoUv2Md+2hcHbOzprAEN3SUyiz4mg58ySA0VBu33 Q5rOXVYUMHbfvk4e9Ef15MtSkKKGqmQ= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JP3SfskJ; spf=pass (imf21.hostedemail.com: domain of dakr@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751124820; a=rsa-sha256; cv=none; b=QOiHYfwOFTSKNbHa3J05FDNtqu9n0kZ9Ex0Ui1efKjJLYwMVxpDAeEJt716/ln1GqdK76/ FBBTWZcvsUR80o1JOwVYxPMU0KW4bXs0phq2xdfdQcPUaMXP7d+zmMkwrBYFziiFs+AyRG yFc5HgrEI5mCQArO7KeymHkdwR2OQIk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id A39F24490F; Sat, 28 Jun 2025 15:33:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED611C4CEEA; Sat, 28 Jun 2025 15:33:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751124818; bh=KGj+3Dao/fmvZlyjkuGLYx3Pal9ZeHYgMyOhMpi0bnc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JP3SfskJgDjbj9JPNS3JtzknCSkvdcwyBeEWXCiR4uowz2HumlPW4XzSPd/UFapWB UPWg2WokcOk9+CT1G7dQgjaZHsvVc/FRFJa4FqxOv0NpvZmamGfYluelrza81MlTqN GDN7iWSCP5v1qBW3Kv/Dw6E0dk3yE8oGnCu1GXIokGujssEyUPZNJLn0v9CAHSnw02 FoIn2Pz1z2+GCgSYM6zGh1SOdQbvqYuEES7jeEt33Tmhv/oBHusnw+RexBua7hrj/K 49e3ybZm1CZu7oGlH4Cv+HZ64zHBm7y94CpV3qSOYFm2Vl1cz1upJLLz2cP52G4D6X 9N1CNmXZDZLtw== Date: Sat, 28 Jun 2025 17:33:34 +0200 From: Danilo Krummrich To: Vitaly Wool Cc: linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Alice Ryhl , rust-for-linux@vger.kernel.org Subject: Re: [PATCH v8 3/4] rust: add support for NUMA ids in allocations Message-ID: References: <20250628102315.2542656-1-vitaly.wool@konsulko.se> <20250628102611.2542910-1-vitaly.wool@konsulko.se> <61DAD282-B00A-4809-B579-3F47F4781BBC@konsulko.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <61DAD282-B00A-4809-B579-3F47F4781BBC@konsulko.se> X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 0468B1C0006 X-Stat-Signature: e8aczuqx9j7h5e8f7nqc5eq3w16ocbmq X-HE-Tag: 1751124819-209060 X-HE-Meta: U2FsdGVkX193Ws5EExHCnT9boOyCRl553mC8Ui9Lz3O14Lsekwf7aSjiz8LMWCnNTGAfWGBiG8Qn4sSeekRDmCvZWWY5lYdJ0/QxPWro3z7cpw6TWimKvVncAyMTvlP1/fQtzWJ7Vki1MKd4DKxHMwVYMGI1b+E387EPmsCv5YSUrBB2O7jyqcXW345jmOaz+al5YU6he7AqLz/k5Xvc6DNsWLx7s6OPxw5uo+dHuNrJ0x+uiPBsGfaOPwBJOHxxJ4S6zGG122TU8qqaMURx7aUYp9fobN5GiRW9/u++eKTEfmrY7Kvzl3hS665/VTDlfKyMM0I2RjrvSUwboq0xOG/1ZhjXAmbpZpZbleNwBslpnvt3FOyWW6RpvIz4LavUKSOBIjCQB3T/ibdYYeEtbfPXv5o8V3MbNuPz1k5WtZy8VV8b82cKIQji3P7CCH1Nq7oKQMBb44cEq9S/701EqVbYKfCyb1dZHa19nJxr4TmrFEoiqOFrxZvSXgdoqf76GZhQqdYyukYlQFFxp/OaoxfbPtbyq4i2rixUi+vFEC+/bg6enEh5zNnCyBoNx/pxcCul/36vVsTm+JO7w9INO4t17akYbWO69wv/8/VdzrBCK7TXKNQPQm0SAsGzycDkbtqVDe/OL7j5mNIKge6tSRNJ0KF1C8i43YvxWubGi+Pa1sLm8h3L3uIL+R2ktTRLoGF2GTfj0jvL75P+r6AT0c177LvJ9dJyIgTLId/1XPoz5aMCoBKyjPLJ/y51y7e4CasXXdMpFmkjkn1ILlKdGrMK+NI6m22dOP3YHb1pUbAIZ0YL6jTOR66ggZuAqRvZNUpZ2va5YczJPO+x4LN2QRTPdgfr+yiEIOc1lFkI8ykLhvJz1Ox2ayyohcmVr4bLWWv4U92fPwYxDjkSmAh8mc/PkPxAMINHUbRYrWOtudI5Rgd3oTTRT4EByUZASCqPUb2K7pm9a23ELp+r/NK HlJQnW4A +g1einWIsSEpCS1O2zqhqsaJj4J2h+ElV400pq5z05ycSJwOkGLyFihAgl6Z+uGkr8kZnolVrp2UC6VYyeUp73szLCp3fKP/32FRkt5r0HVI5hsQsh92nMwHZLNSCSr9zwSJwrRZJVgNvueqazQrPf4yaqLqLvu/PZTXFt/cs1oHadXYyAwxfDvphZdU8mud4e6cMKJGLz+zUOec2fBW0o2kl1mIfz0OMVFnCfMfux65PG/aH4iOGf7lgEG1A6a4/9OY0603lRyeHZiZwfjlWVYS3rvhI75sSsXuz8ed86UURn1g= 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 Sat, Jun 28, 2025 at 05:25:52PM +0200, Vitaly Wool wrote: > > > > On Jun 28, 2025, at 2:21 PM, Danilo Krummrich wrote: > > > > On Sat, Jun 28, 2025 at 12:26:11PM +0200, Vitaly Wool wrote: > >> +/// 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 is specified > >> + pub fn new(node: i32) -> Result { > >> + if node < 0 { > >> + return Err(EINVAL); > >> + } > > > > Should we also check for MAX_NUMNODES? > > Good point, thanks. > > > > >> + Ok(Self(node)) > >> + } > >> +} > > > > > > > >> + /// Re-allocate an existing memory allocation to satisfy the requested `layout` and > >> + /// optionally a specific NUMA node request to allocate the memory for. > > > > It's not an Option anymore, so we may want to drop 'optionally'. Also please > > leave an empty line here. > > > >> + /// Systems employing a Non Uniform Memory Access (NUMA) architecture contain > >> + /// collections of hardware resources including processors, memory, and I/O buses, > >> + /// that comprise what is commonly known as a NUMA node. > >> + /// `nid` stands for NUMA id, i. e. NUMA node identifier, which is a non-negative > >> + /// integer if a node needs to be specified, or NUMA_NO_NODE if the caller doesn't care. > > > > Please also explain what happens when the NumaNode changes between calls to > > realloc_node(). > > > > Does it have to remain the same NumaNode? Do we need a safety requirement for > > that? > > Since we don’t implement that logic, we trust the C part. The current implementation will refuse to realloc for a different node, and I believe that is the right thing to do because transferring an allocation to a different node doesn’t go well with the concept of simple adjustment of the allocation size. > > Do you believe it is necessary to explicitly state it here in the comments? Yes, we should document what can be expected to happen in this case, i.e. that it will cause an AllocError.