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 007E5C83F17 for ; Thu, 10 Jul 2025 18:58:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9967F6B009A; Thu, 10 Jul 2025 14:58:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96E7B6B009B; Thu, 10 Jul 2025 14:58:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 884726B009C; Thu, 10 Jul 2025 14:58:04 -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 74E146B009A for ; Thu, 10 Jul 2025 14:58:04 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 43650BE0ED for ; Thu, 10 Jul 2025 18:58:04 +0000 (UTC) X-FDA: 83649264888.19.EBD5B7F Received: from mailrelay-egress16.pub.mailoutpod3-cph3.one.com (mailrelay-egress16.pub.mailoutpod3-cph3.one.com [46.30.212.3]) by imf09.hostedemail.com (Postfix) with ESMTP id CEAF514000C for ; Thu, 10 Jul 2025 18:58:01 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=59u0gWhR; dkim=pass header.d=konsulko.se header.s=ed1 header.b=Z6euGjn8 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752173882; 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=qOROnEfbRMkEU9HUIlrw8G/gc7MbaqKeDQV/AuFw0LU=; b=wE76hMEDLHstxdpITQORjp0GtGwWCh7YVZeAiMACFkbYjA752M/jAwBJa1Ov16amZMSrnm OPxWEjpX0myPMmpE+EZvTy8o0Yb4SZUIzEPVCiBbfDmUMpoX6UeRfNQiBNcMFhVn+bbb89 ZsPeyGWTGit4F2iM2KkLb7u3dpzTcb0= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=59u0gWhR; dkim=pass header.d=konsulko.se header.s=ed1 header.b=Z6euGjn8; spf=none (imf09.hostedemail.com: domain of vitaly.wool@konsulko.se has no SPF policy when checking 46.30.212.3) smtp.mailfrom=vitaly.wool@konsulko.se; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752173882; a=rsa-sha256; cv=none; b=QtL9z/rabA99wC81vnYbJvIbjOK58hZx6zg8PVXWXnJEjuZ5Bf85LI42jCyqaQsGmfr2ej BPkgnKwemoun+dsPnUja+244jyJPcw3hqY0A8NFxr/noLyIF7gBEG5NLK/e+Fd9LVkzq9M fWa/Y0yNINjP3ecszq6GMGKqPqiJKeo= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1752173879; x=1752778679; 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=qOROnEfbRMkEU9HUIlrw8G/gc7MbaqKeDQV/AuFw0LU=; b=59u0gWhR/XhR/i5COmwjWdLGRDxP9xDXHDopl2OUB0iq94dLbpEeYI7Vz1wimKDxihVFX59SQmx+V 4IrlXC7v64t9gScthV2gZhTtx+AzVXPmuO6lqlvgbUHCRVJurwRE6W+yLK+m71O/CWRks6wFn7wvyC 1srhBrdDsj6lXbdNNVWqQbs26VS/nXQH6SzfgsR8amVggugx648AYHZmJAThmuZnloO6LgMLB/Myxg XY3CWlKactui0SrgVoLBfB2EhQBLRH+fqfQDGSqv9uzvosBsOgiC9Yp9gqFZlT1s4cJKfnT9bRXKmG lD7N51RK0yaCSc/InhrGXh4Jfb4SIJg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1752173879; x=1752778679; 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=qOROnEfbRMkEU9HUIlrw8G/gc7MbaqKeDQV/AuFw0LU=; b=Z6euGjn8Mwt0J/TG8fUhvLbVRpyUb5j4Wf9Bv9akAk10Z6B/49l8SclhsQwGW5lI0CgIAMtsb89gN /5kL9yNBA== X-HalOne-ID: cb161d63-5dbf-11f0-b814-e90f2b8e16ca Received: from smtpclient.apple (c188-150-224-8.bredband.tele2.se [188.150.224.8]) by mailrelay2.pub.mailoutpod2-cph3.one.com (Halon) with ESMTPSA id cb161d63-5dbf-11f0-b814-e90f2b8e16ca; Thu, 10 Jul 2025 18:57:58 +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 v12 1/4] mm/vmalloc: allow to set node and align in vrealloc From: Vitaly Wool In-Reply-To: Date: Thu, 10 Jul 2025 20:57:48 +0200 Cc: "Liam R. Howlett" , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Uladzislau Rezki , Danilo Krummrich , Alice Ryhl , Vlastimil Babka , rust-for-linux@vger.kernel.org, Kent Overstreet , linux-bcachefs@vger.kernel.org, bpf@vger.kernel.org, Herbert Xu , Jann Horn , Pedro Falcato Content-Transfer-Encoding: quoted-printable Message-Id: <2D8A1A29-C847-479F-B732-A7CB13A46FA7@konsulko.se> References: <20250709172345.1031907-1-vitaly.wool@konsulko.se> <20250709172416.1031970-1-vitaly.wool@konsulko.se> To: Lorenzo Stoakes X-Mailer: Apple Mail (2.3826.200.121) X-Rspam-User: X-Rspamd-Queue-Id: CEAF514000C X-Rspamd-Server: rspam09 X-Stat-Signature: dt6himnnpwyb5puk6d11sj6cz16asrfb X-HE-Tag: 1752173881-445962 X-HE-Meta: U2FsdGVkX1/sV82AaX/H4+hjz3CBzeu/gu64CBKwNzmdg2zD5bs9awZCPPi3v/u/xTbwRuVpq04q7fF0bOvk+x96/AxOpBcNzc08b5g9nHPSOEp7HZWtFuJAA68pgEoNYeMkFKrmcZkrBzkWyUf8Dhx9befRKEmKLSzGdNNKp4JhId/KvRsy4/dhdzkZF6QQ1HOH6lSSysZok8XPNJS0NalkiHiACukRnkkZPwiX2P6/pA1sGQY4wjN9pVkPTuJExYAR1+TpVNS2rLSDar/vLzETQ9IBzmCzGkEbQM4Ew2I42NtSOku/l14CTl2SzRSuWXRubkgjnaK4l5v9/dYyeCI81uKFFZZ6YT8bLkGB2qmhazC4qJFUWO5nADc6GVpe/pAD+bYH7qQXuWzQyWfIaW+8uzr6nIHrJ+ICM/i0Fqh4ePHYZMUGjSEupmKzDejqlqTSPqrxkphZfNWeoa2YgOFPzppD6wb+LroCf8k0Ck0CRMe3+U1wj8c2LHSU0vkdbNJFxwv8ja7gYMk/WxKrpFKfHKMAfGe5zzjoG6IXSDAIyuq6V29Ak5Qj8dTIRQJWHNN6Fmt7msRh9J9Pj4DO/cfUDQl5BAS795l4tQfbAIOxoMwbWxvzLszTJGj2GsSC4ldviel8Ux/co68famkg4raD38XhSw7zLfFxuLD9479vgDNkPrj2FcszbHgo/GQDOuSNsaGarCTRouc3WJhkY48J5hubS7Nw1uvHJDByfS1oxkeOQqUZSOLIph6DYcfj13SAuPMykHgvdMKwO36XIT25eh7BSDiYxhnQP8YdMavU7Ip3jMvzky1rnf0UlU4s+227WoNBnZg+dzUwPjFctn7PGBkExwsm5zyodEyyPfRGuAPakKop0yht4SToSLOY0TCBkQCbtLF4Cx1OuIi+sRgAUtfg1E2kr01UsZf0gXMwrnZHP9QT3fOd2H+8bbvud0po3DzcdaEA5QLXUp5 7Qyv1qT3 5id81EjNsLItnvElzejoxFy6+wb7NmwOJt7HdSS0nPNM3M7Nyzqjgvbs3g7DDaPPG/ciVhaKV0AzBVYv2SJFUwL19pXb9RbwH6W3feM2ErV5AmK+O8/TpUxdRkOScX1I52dlKINYr5P6fywpTWsnFXKcE6GTHJ+4qaT1h6wOgkMDiMs7HIEKkM+f0zSWd9QngZcRcoIe12dlXRpOTliqgOxE5FCoaSXlkziQapuD1KLxXi/Y= 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 Jul 10, 2025, at 5:19=E2=80=AFPM, Lorenzo Stoakes = wrote: >=20 > On Thu, Jul 10, 2025 at 08:21:19AM +0200, Vitaly Wool wrote: >>=20 >>=20 >>> On Jul 9, 2025, at 9:01=E2=80=AFPM, Liam R. Howlett = wrote: >>>=20 >>> * Vitaly Wool > [250709 13:24]: >>>> Reimplement vrealloc() to be able to set node and alignment should >>>> a user need to do so. Rename the function to vrealloc_node_align() >>>> to better match what it actually does now and introduce macros for >>>> vrealloc() and friends for backward compatibility. >>>>=20 >>>> With that change we also provide the ability for the Rust part of >>>> the kernel to set node and alignment in its allocations. >>>>=20 >>>> Signed-off-by: Vitaly Wool >>>> Reviewed-by: Uladzislau Rezki (Sony) >>>> Reviewed-by: Vlastimil Babka >>>> --- >>>> include/linux/vmalloc.h | 12 +++++++++--- >>>> mm/nommu.c | 3 ++- >>>> mm/vmalloc.c | 31 ++++++++++++++++++++++++++----- >>>> 3 files changed, 37 insertions(+), 9 deletions(-) >>>>=20 >>> ... >>>=20 >>>> diff --git a/mm/vmalloc.c b/mm/vmalloc.c >>>> index 6dbcdceecae1..03dd06097b25 100644 >>>> --- a/mm/vmalloc.c >>>> +++ b/mm/vmalloc.c >>>> @@ -4089,19 +4089,31 @@ void *vzalloc_node_noprof(unsigned long = size, int node) >>>> EXPORT_SYMBOL(vzalloc_node_noprof); >>>>=20 >>>> /** >>>> - * vrealloc - reallocate virtually contiguous memory; contents = remain unchanged >>>> + * vrealloc_node_align_noprof - reallocate virtually contiguous = memory; contents >>>> + * remain unchanged >>>> * @p: object to reallocate memory for >>>> * @size: the size to reallocate >>>> + * @align: requested alignment >>>> * @flags: the flags for the page level allocator >>>> + * @nid: node number of the target node >>>> + * >>>> + * If @p is %NULL, vrealloc_XXX() behaves exactly like vmalloc(). = If @size is >>>> + * 0 and @p is not a %NULL pointer, the object pointed to is = freed. >>>> * >>>> - * If @p is %NULL, vrealloc() behaves exactly like vmalloc(). If = @size is 0 and >>>> - * @p is not a %NULL pointer, the object pointed to is freed. >>>> + * if @nid is not NUMA_NO_NODE, this function will try to allocate = memory on >>>> + * the given node. If reallocation is not necessary (e. g. the new = size is less >>>> + * than the current allocated size), the current allocation will = be preserved >>>> + * unless __GFP_THISNODE is set. In the latter case a new = allocation on the >>>> + * requested node will be attempted. >=20 > Agreed with Liam, this is completely unreadable. >=20 > I think the numa node stuff is unnecesasry, that's pretty much = inferred. >=20 > I'd just go with something like 'if the function can void having to = reallocate > then it does'. >=20 > Nice and simple :) I think it is important to stress that the function is not always = following the specified nid. How about =E2=80=9CIf the caller wants the new memory to be on specific = node *only*, __GFP_THISNODE flag should be set, otherwise the function = will try to avoid reallocation and possibly disregard the specified = @nid=E2=80=9D ? >=20 >>>=20 >>> I am having a very hard time understanding what you mean here. What = is >>> the latter case? >>>=20 >>> If @nis is !NUMA_NO_NODE, the allocation will be attempted on the = given >>> node. Then things sort of get confusing. What is the latter case? >>=20 >> The latter case is __GFP_THISNODE present in flags. That=E2=80=99s = the latest if-clause in this paragraph. >>>=20 >>>> * >>>> * If __GFP_ZERO logic is requested, callers must ensure that, = starting with the >>>> * initial memory allocation, every subsequent call to this API for = the same >>>> * memory allocation is flagged with __GFP_ZERO. Otherwise, it is = possible that >>>> * __GFP_ZERO is not fully honored by this API. >>>> * >>>> + * If the requested alignment is bigger than the one the = *existing* allocation >>>> + * has, this function will fail. >>>> + * >>>=20 >>> It might be better to say something like: >>> Requesting an alignment that is bigger than the alignment of the >>> *existing* allocation will fail. >>>=20 >>=20 >> The whole function description in fact consists of several if-clauses = (some of which are nested) so I am just following the pattern here. >=20 > Right, but in no sane world is essentially describing a series of = if-clauses in > a kerneldoc a thing. >=20 > Just it keep it simple, this is meant to be an overview, people can go = read the > code if they need details :) >=20 Alright, no strong feelings about it anyway. Will reword as you guys = suggest. Thanks, Vitaly