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 D3809C8302F for ; Tue, 1 Jul 2025 11:16:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3C0DB6B00A0; Tue, 1 Jul 2025 07:16:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 371606B00A3; Tue, 1 Jul 2025 07:16:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2606E6B00A4; Tue, 1 Jul 2025 07:16:09 -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 105496B00A0 for ; Tue, 1 Jul 2025 07:16:09 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C9028C02CF for ; Tue, 1 Jul 2025 11:16:08 +0000 (UTC) X-FDA: 83615441616.09.173B876 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf16.hostedemail.com (Postfix) with ESMTP id B53D618000E for ; Tue, 1 Jul 2025 11:16:06 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q+7NRq86; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751368566; a=rsa-sha256; cv=none; b=PAtt2WpyCRy7aWmVIqfHOdYIETfbbgrlCFupRDp/I3+04aykNu6HFZ7cCQPllwiew4ik03 6u7mNgdaa7amUaWu7m1+SbssIi1DXM2a7bKOOVuwBpqveC9OIPKoqAvdfVLEFLpzRjpTi4 JRgRP1UnZlpTrN+6TB3FpwkmnosdZ+8= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Q+7NRq86; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf16.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=urezki@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751368566; 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=RW+hX+cQCyvacj8gxDCQmCJ1cgJrO4Ch8WdKLpegjyg=; b=Vmb3B30ujJysnjR9yLbu/xLG7ski0/c6/IWIWb+cn31MuT/Z+1Zjy/ZuEnF25hqv0xCF5V qEPcJ0PXB3fnWAPVZz6JMK/Q3j9fSnvQPna6xxvbZsC2H/TcSjoJiBJZ1tIv4QsDxchXlZ VClTfkXN6Vi0SSaIF4Hw7YI7dBTyqdk= Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-55516abe02cso2717973e87.0 for ; Tue, 01 Jul 2025 04:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751368565; x=1751973365; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=RW+hX+cQCyvacj8gxDCQmCJ1cgJrO4Ch8WdKLpegjyg=; b=Q+7NRq86SieqQKHL14sKrKPYNaJ0jR5HyEjX/v0/BIGwPIJfl3ipdfb2S8KGjY4nUC o/SiuQrJ+1yPRN5V0RjPzjfSl/sz/3TMoJfpkAujCPjrn+xDj0Fah0kP5B2h2ty6Ig9i FBwQIlpQj3Q/atVJ6YdCKdoVAhD2GO5T1tl/i0hT7rcNH9r75TlTuCZEFo7iqK+K3d6a Ih6XL7yiMBpwwUZjcMwzZ3aL5j9EH8iCF2LebwG+NaF5HsEr91VX2GiDPbtp4ts9KoyA K8cK7RyIUVcw2B5UZMow0BMLujeSphLJQILHgAu/gMc31JKiont23oR3sXth1ByzsvcY WilA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751368565; x=1751973365; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RW+hX+cQCyvacj8gxDCQmCJ1cgJrO4Ch8WdKLpegjyg=; b=G9Fn8sHyGiHArgUqSPzzEu3bGaYrM7pgn/XtDiDzrWlm0lqliHhcP8mkImEUr5Tad1 9jrrY1ECkWilQirCFkA3LgPFOnzBr3BFbMnEpOFjdyvU/0KimOZJeqnK20YP9QCJa+q8 k2tVGMuBB0q2qMy5YCs9L6NBXtVrnf6tw84wlRXSmoZA06kzOu0IFDVUS59DhzG30aYc zOH+vm2gx+os3Sj2iWPreGyvYmh+FYP+ws9lAIGaRgf6gKvxZBMkYaViv1yMJ5xeNYoi kE/YjbNX6d5fCz0ZZv/bl5XecLAhwqE7Dd80Wctie0kkhAnUVvqw/dx8tUf3QLRvLLjc /OqQ== X-Forwarded-Encrypted: i=1; AJvYcCWOEDZK80nFGxSqfunQSP9j4cX0nF8ErZM1+a8ETznjoOnd6LUwzTgV4+aydFQMRgoiIpdQH3Da6w==@kvack.org X-Gm-Message-State: AOJu0YzuAGcsOqqP9nCmuS+jSzj+LwoDsJqeQJc/VjdBhrWPpfcp1768 2uqTcR4CcM0B33tz/qXqo2WhH43upZhkVUsvvi22iNr6MKL3HNxttCsOFN6jIQ== X-Gm-Gg: ASbGncvGORdm0j1FZA85lN9ZWrPc3eAryVNMN2nfGKqgW0Lr/li+qH+T+zvf2G6cgCg UJhjHRw+M5YDATHwj0KvtxdTf8NGNuxXL4YWJ3TyjQh6eRFxzsOVoUAyV0Msl3v3dRTJXy011p4 fNwDokzHbYdHXwFuQv9LuBsscUW1UJezGgQTozdlE1QlPdUw+6xvcODbcEXnT+AXhkhoTCgxsES xQoiq4GQDvwxuszQdMhGFk02H0dZcl5By08D7YY7P5bJuka/J+Zrw8/m1181L0OHwKWxlRyi4NZ FGuSQmnBbKQsl/F3Tr1OKyUU5FR1xJ7bH6/ou54kmrp2BLbjHkfVsFKhSHkvFYMhUMl7uYc/dWv R5rBIXdr/Wu0= X-Google-Smtp-Source: AGHT+IH7beHmzryKHMnEptA76HGQNtp9dSvozMXm0SLIjavGHfqq5azRcWWkcV18tUriffM+X03KIQ== X-Received: by 2002:a05:6512:33ca:b0:553:a294:3f8 with SMTP id 2adb3069b0e04-5561f8983e2mr965176e87.14.1751368564504; Tue, 01 Jul 2025 04:16:04 -0700 (PDT) Received: from pc636 (host-95-203-1-180.mobileonline.telia.com. [95.203.1.180]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5550b2b95b7sm1774918e87.108.2025.07.01.04.16.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jul 2025 04:16:03 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 1 Jul 2025 13:16:01 +0200 To: Vitaly Wool Cc: Uladzislau Rezki , linux-mm@kvack.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Danilo Krummrich , Alice Ryhl , rust-for-linux@vger.kernel.org Subject: Re: [PATCH v9 1/4] mm/vmalloc: allow to set node and align in vrealloc Message-ID: References: <20250630221511.3325123-1-vitaly.wool@konsulko.se> <20250630221615.3325221-1-vitaly.wool@konsulko.se> <31E257E1-AB52-4115-A264-56F545AB84A9@konsulko.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31E257E1-AB52-4115-A264-56F545AB84A9@konsulko.se> X-Stat-Signature: oziem4k9hxkozpn1brzeco15813d7qao X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: B53D618000E X-Rspam-User: X-HE-Tag: 1751368566-175763 X-HE-Meta: U2FsdGVkX185cNS7KXPWtzWqcpPl5omMAgML61+Hfs0z1nGuS4WTKKidzniF+31As2C+xkVihWlFbTeXhotBhkjrilfvY+Ai0Oq1IdZzTrimJ8l1kFP7pCPlj0CYhwmU8/mEaJgOK04XxAc+wiWAdlqE9tn7WR4XgHxh5hSNrLTb/h4SeqCcE88rjvOUOJ2TnvTunVUjS2esCPzl77sn27sINBZeWqFBm8rGHt/j83hBGwezONtSzmx8mvPda09IOpmS7pY931YcxQ4bHT+vVeHWTGAOYt4jss090HSlmn6GnKequZsikb2TbM0pgnTEoe9IOrWgQaZr6nGPVAN4s84PpauO8Kqva4B+gZnBgFQ5NO3SP54MDyVR8XzQg4v45GLa+uEhu9HH+xUtEM1dG1lIiBsfC9GkteLWqwXPb3lirGvMmosd7Znmsubr55BRzwEkMi8m+JVSBrRXx5F4EA0R63DL15OKgLZ9KSpLbgX9H+bA8T8i2yRkPHZSNTlXW8SzVneLbs5T+QaKoHyL/D5HgsGq8aN7aPuoil9S9AgaGHj95WaGcmllSIpwOVENe6qQxE+zrpSO1JI5ZCrecJWneRkQsgE40jo5xO+cuSvs7ipUIMpNrxR0smQHh7wDnVO965AaL//Ibo3ptkUn7+PVUETQL4pM9EWXdoUVVtGPFGK/ovCPa+uX/BKQnLh1Blb3ENoLt8ottvaERhUcWWrM/FBtg9HLhBBWecgXtcWZVK8UiT1SZmAwmt0hDMz2qxN/AIX0pjUYCpJ69yS0uGGh17AdeAwPIGJM2itT4ax4oWDtZcq4bBiTtd+rs/uV3U4ASkT3zI1mOo3pq4wzheQxn3wXU2WsTgdoCVdZBOHHtTDbMtWH/HKWg3VIpuTGoC/aoI7QiZGGbdWc2oU2p2leSyUWOgkM3PRxmtCqNi1rX4pVP/sSpmtjZnOhrJKp8j9olndf/a1NAu4KPX7 j3h2F+Io Tst8Qcop5qFgJ0rT8dGvQTzZgLhDBKGKzcGkagLJ9KyEmN5Gt/04bxKcbA9gwDhay3MNA/oOsWRgjmhisd0AGAJ3LSikiFbngyQ8ycpK6/Evga+b60KAIDmLNbrU/8UbLHoMi96faFyrtEeyVpHer4YMPhjcJrSKJhItrMpTYqchqSxPxxXwDLgQZxqLCmnThoSb6KgTcvsCB+PeJKLcVxoAxgpnqNtTO3Y7HVNMawVTbabId2VqCvjkLl+I6YHPh0URJ+yw1vvgKW4sjTxREiIxeU9TExVN0976efgF37dZKDZntTFToZoztilf6v7pkJTFKw568AQ5kbVMjP0Nl3Fbu76bO4I6une8ha8WQpJhbnWhzB+RX8Agjz3Dd1OX8PuhzpNfWmMLviLmubkNjLcgdKKJhWAIZdalqKiJ9iBU9mWAY7NUjeC4y+dzvX1E7b1rDkDS4vid5eDH8SCK2fEpMR2VdmphuHb1Itjpx5U8UQoTbEjfAiOOsv8Ejpb41+CZS 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:54:36PM +0200, Vitaly Wool wrote: > > > > On Jul 1, 2025, at 12:50 PM, Uladzislau Rezki wrote: > > > > On Tue, Jul 01, 2025 at 12:16:15AM +0200, Vitaly Wool wrote: > >> 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. > >> > >> With that change we also provide the ability for the Rust part of > >> the kernel to set node and aligmnent in its allocations. > >> > >> Signed-off-by: Vitaly Wool > >> --- > >> include/linux/vmalloc.h | 12 +++++++++--- > >> mm/vmalloc.c | 19 +++++++++++++++---- > >> 2 files changed, 24 insertions(+), 7 deletions(-) > >> > >> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h > >> index fdc9aeb74a44..68791f7cb3ba 100644 > >> --- a/include/linux/vmalloc.h > >> +++ b/include/linux/vmalloc.h > >> @@ -197,9 +197,15 @@ extern void *__vcalloc_noprof(size_t n, size_t size, gfp_t flags) __alloc_size(1 > >> extern void *vcalloc_noprof(size_t n, size_t size) __alloc_size(1, 2); > >> #define vcalloc(...) alloc_hooks(vcalloc_noprof(__VA_ARGS__)) > >> > >> -void * __must_check vrealloc_noprof(const void *p, size_t size, gfp_t flags) > >> - __realloc_size(2); > >> -#define vrealloc(...) alloc_hooks(vrealloc_noprof(__VA_ARGS__)) > >> +void *__must_check vrealloc_node_align_noprof(const void *p, size_t size, > >> + unsigned long align, gfp_t flags, int nid) __realloc_size(2); > >> +#define vrealloc_node_noprof(_p, _s, _f, _nid) \ > >> + vrealloc_node_align_noprof(_p, _s, 1, _f, _nid) > >> +#define vrealloc_noprof(_p, _s, _f) \ > >> + vrealloc_node_align_noprof(_p, _s, 1, _f, NUMA_NO_NODE) > >> +#define vrealloc_node_align(...) alloc_hooks(vrealloc_node_align_noprof(__VA_ARGS__)) > >> +#define vrealloc_node(...) alloc_hooks(vrealloc_node_noprof(__VA_ARGS__)) > >> +#define vrealloc(...) alloc_hooks(vrealloc_noprof(__VA_ARGS__)) > >> > >> extern void vfree(const void *addr); > >> extern void vfree_atomic(const void *addr); > >> diff --git a/mm/vmalloc.c b/mm/vmalloc.c > >> index 6dbcdceecae1..776c68f84ce2 100644 > >> --- a/mm/vmalloc.c > >> +++ b/mm/vmalloc.c > >> @@ -4089,12 +4089,15 @@ void *vzalloc_node_noprof(unsigned long size, int node) > >> EXPORT_SYMBOL(vzalloc_node_noprof); > >> > >> /** > >> - * 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 id > >> * > >> - * If @p is %NULL, vrealloc() behaves exactly like vmalloc(). If @size is 0 and > >> + * 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 __GFP_ZERO logic is requested, callers must ensure that, starting with the > >> @@ -4111,7 +4114,8 @@ EXPORT_SYMBOL(vzalloc_node_noprof); > >> * Return: pointer to the allocated memory; %NULL if @size is zero or in case of > >> * failure > >> */ > >> -void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > >> +void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align, > >> + gfp_t flags, int nid) > >> { > >> struct vm_struct *vm = NULL; > >> size_t alloced_size = 0; > >> @@ -4135,6 +4139,11 @@ void *vrealloc_noprof(const void *p, size_t size, gfp_t flags) > >> if (WARN(alloced_size < old_size, > >> "vrealloc() has mismatched area vs requested sizes (%p)\n", p)) > >> return NULL; > >> + if (WARN(!IS_ALIGNED((unsigned long)p, align), > >> + "will not reallocate with a bigger alignment (0x%lx)\n", align)) > >> + return NULL; > >> + if (nid != NUMA_NO_NODE && nid != page_to_nid(vmalloc_to_page(p))) > >> + goto need_realloc; > >> > > By this goto change, you bypass the two important checks below. For > > example if you shrink the allocated size, you do not need to perform > > any allocations. Instead the patch goes and allocates a new area. > > > > You just need to remove: > > > > - if (nid != NUMA_NO_NODE && nid != page_to_nid(vmalloc_to_page(p))) > > - goto need_realloc; > > > > to make it working. > > > > I am not sure I’m following. If we get a request to reallocate for a different node then we should either reject it or do the new allocation for this new node and copy the data to the new place. Shrinking the allocation on the old node doesn’t seem to be right. Or am I missing something? > If your process migrates to a new NODE, which is fine, it does not mean that you have to perform all this bouncing movement(reallocate on a new node). Next time it can be migrated back. Process are allowed to migrate and access to a remote memory. Let's keep it simple. -- Uladzislau Rezki