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 49159C83F09 for ; Thu, 10 Jul 2025 06:16:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DEF946B00A3; Thu, 10 Jul 2025 02:16:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC6ED6B00A6; Thu, 10 Jul 2025 02:16:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDC9B6B00A8; Thu, 10 Jul 2025 02:16:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id BA4816B00A3 for ; Thu, 10 Jul 2025 02:16:39 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6A71B804A0 for ; Thu, 10 Jul 2025 06:16:39 +0000 (UTC) X-FDA: 83647346118.26.DF67588 Received: from mailrelay-egress16.pub.mailoutpod3-cph3.one.com (mailrelay-egress16.pub.mailoutpod3-cph3.one.com [46.30.212.3]) by imf28.hostedemail.com (Postfix) with ESMTP id 10D96C0012 for ; Thu, 10 Jul 2025 06:16:36 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=j38hk03L; dkim=pass header.d=konsulko.se header.s=ed1 header.b=25EqmBEl ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752128197; 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=bbG2eOYm0nVPoiyoh0kqZFxhcAwfAfhJmOsqqTLYURg=; b=i6p8s9vqLi53uQc2j7ijjAGHueoczKUoxhjVtm8jKkSvIkN6Sxw8B6maezmA9vuWi+YNkT l9IMKgouU8uU3AFd98JWXT0EKub8T2yZdeptSc0kPOsE16NyUh7oCVfLAK4GzLIzMVO5Rx yOdoxEy/DkVFpTwWTeKMCEmqs0mmE5s= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=konsulko.se header.s=rsa1 header.b=j38hk03L; dkim=pass header.d=konsulko.se header.s=ed1 header.b=25EqmBEl; spf=none (imf28.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=1752128197; a=rsa-sha256; cv=none; b=UfplyTMqPEzLBS97EqtUmBNFUXa1pEo7aqJemuCx4GlwEB6hye1JA22tUZmI+06XQMNqjT bWcOjif6+HjXj8THFjGp4omWi43n/MzFT4KktG4lx40Zk2KAoIFDRzHfV49HWsJUs2Zamt qpkL3TUWPc5KLvoGCpYtVpmL3HMBvnI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1752128194; x=1752732994; 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=bbG2eOYm0nVPoiyoh0kqZFxhcAwfAfhJmOsqqTLYURg=; b=j38hk03LBQ49WWec0sDiZUsKSxLsQrfrEaZMs1r573dhGXIx+sVrsXxu/HgQlR7k0yJSRB4ON1Ice tG0FJEY2wjQbCIUE4gv4IohxNaKPGMHh+F/2lzjaBJKHS0mg4Kn7Mj9HQ53w3Zur6DelJBbQXiTI+U BQRIvFJEnohGKdB5mrpRP6EgiC+LMzfOgLUlEaNlBkCAd9cujAPvnz8yjNg7+0Zn2g1JxNxWqyfIW3 oN0jo/sjn6fZjtmkBaLvQOZTBqheYe/wI4NN2w2BLVGqj74qypbRrmwR54e0wlcpIZqoKdxrm8c+5x zJfPhXRb//Kze4IWNZpY7y7Rr1hujUQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1752128194; x=1752732994; 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=bbG2eOYm0nVPoiyoh0kqZFxhcAwfAfhJmOsqqTLYURg=; b=25EqmBEl3UcQ3f9/U1QLHscuEdIF/PGEea91SZXE194mrLPt5Tl4+oxQwNJYCjyaqeBF95E9WOm64 lcFHs7eAg== X-HalOne-ID: 6c6be782-5d55-11f0-8215-f7376af24660 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 6c6be782-5d55-11f0-8215-f7376af24660; Thu, 10 Jul 2025 06:16:34 +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 08:16:23 +0200 Cc: Danilo Krummrich , linux-mm , Andrew Morton , LKML , Uladzislau Rezki , Alice Ryhl , Vlastimil Babka , rust-for-linux , Lorenzo Stoakes , "Liam R . Howlett" , Kent Overstreet , linux-bcachefs@vger.kernel.org, bpf , Herbert Xu , Jann Horn , Pedro Falcato Content-Transfer-Encoding: quoted-printable Message-Id: <9F14B44F-6073-4F12-875A-9E07EFC16E20@konsulko.se> References: <20250709172345.1031907-1-vitaly.wool@konsulko.se> <20250709172416.1031970-1-vitaly.wool@konsulko.se> <14b08e7c-c2e8-435c-a1dd-bd51cfb42060@kernel.org> To: Alexei Starovoitov X-Mailer: Apple Mail (2.3826.200.121) X-Rspam-User: X-Rspamd-Queue-Id: 10D96C0012 X-Rspamd-Server: rspam09 X-Stat-Signature: w8ikhwu4xpr7y4m9prdqczd6r3owndqg X-HE-Tag: 1752128196-43300 X-HE-Meta: U2FsdGVkX1/w+Ygyg/p6g38y/1hDIIkGP4TSXMnxEWdsRWobgh+5D+yBlq0c6NEyN6/0M+z2dVPvLeMHZGdJb8pQ0wNlZ1igVsfXBBtK38dUooW4TYUM17jgPlwQJt/d33+QbGvT86OrhTRY9hfAg2Krvs2cE3eP1fLombGg1p5DUHOw00dcH7KG7A6XyFZ3aDP2CFTJ57lwqxk5Alax8SAVTt/VyRp/dfZ+IyPlnVh5O2mvVPZMBhqO4UpqkDEOL2VFxjzCFYHjo2P/AUMBCM6ADgsMXg28OTAnljZDh7QE32ct9F78I/usSnW8pWY+Vw8l8jR2K4ECvARzmJV1IkSbWFBVDAD0ukdUU5waU40qNudxFqqzz03MQ+XzaK7aayuauOt5vvlUZtUH7zDGOultQZAdtauP9yFBn2x5wfYCjXixgrbmpVmwU8GuAfDjsH+hXmB//PZ9e1eYP+p0IlfphUTV8243HUguyhmUjyMASy76tO762YiPUKMxjHeGzFJuijE35eKhnelqjmvP3PMJnADqYc4O0pFKTFSbgfliYyZAJ6TwNUYlF7LBMucvy+L0kfcs04OT3C6IFYCDlbwjtnFmVLS+AIipgBvOQzEXwSpcTwUoXKNTcXjOUMMR5q+MYu6wB+gGapYQawDS4p4Mh873zIjgEotsSIQJ8YNux32v8OM09IxFDQCauvLjlCeTtIIFYIDIc4iDtjHxPX+ZTx7BN15wEcf9rCb0OTCcz1KKH1IpwzRKpRiCBM+27NZa36G6ogDAGuujqSYZLHazlJ5NlsoGQc/afonza61tUEXDyDV3hybLVH0GGzt/VUp1ReH8ggDPmJt7Pu0HM9J8R9iW6jGsToHGbDBIHyBRD9DahDiM29OFqe2UpGH0PLvsXmB1XMKGHZx78TdGjrIAaJBjFpGoA4U3ksoc0a5xDjXjFGuyFh15R4cbUEG7HYBYHfaiA3xSW6c0PMk Bm7Uhzmt iWwHLtoiWO5xljQ/lUvXhnTSQDOzXTx55eKl/8SQO9FSdKZDKYf3b6DSXkEreTLIAjIeQDtUUxsCNn/RcwDZ0v4cB5br04PvaNZir2w6yjivNE/ojEZo3LHYVHkG6Z5ZbuL2xHGKSh05DET9g8ibtIeFta7pmupnUuSaLYoGgdWibV/CDNcKhTfKD3NnkftOy0lHk/0g2jDVhJf2aow8l0OQqd+vJItORVKeEVGDSr2NBWUkB42pUAzz6Xqon2neLa/42VWpFBGrbPAFiZw2kg1YbBeYh85INIuDftZNKOc4tV9Ae0Svw160Fkg== 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 2:39=E2=80=AFAM, Alexei Starovoitov = wrote: >=20 > On Wed, Jul 9, 2025 at 4:26=E2=80=AFPM Danilo Krummrich = wrote: >>=20 >> On Thu Jul 10, 2025 at 1:14 AM CEST, Alexei Starovoitov wrote: >>> On Wed, Jul 9, 2025 at 3:57=E2=80=AFPM Danilo Krummrich = wrote: >>>>=20 >>>> On 7/10/25 12:53 AM, Alexei Starovoitov wrote: >>>>> On Wed, Jul 9, 2025 at 10:25=E2=80=AFAM Vitaly Wool = wrote: >>>>>>=20 >>>>>>=20 >>>>>> -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 node) >>>>>> { >>>>>=20 >>>>> imo this is a silly pattern to rename functions because they >>>>> got new arguments. >>>>> The names of the args are clear enough "align" and "node". >>>>> I see no point in adding the same suffixes to a function name. >>>>> In the future this function will receive another argument and >>>>> the function would be renamed again?! >>>>> "_noprof" suffix makes sense, since it's there for alloc_hooks, >>>>> but "_node_align_" is unnecessary. >>>>=20 >>>> Do you have an alternative proposal given that we also have = vrealloc() and >>>> vrealloc_node()? >>>=20 >>> vrealloc_node()?! There is no such thing in the tree. >>> There are various k[zm]alloc_node() which are artifacts of the past >>> when NUMA just appeared and people cared about CONFIG_NUMA vs not. >>> Nowadays NUMA is everywhere and any new code must support NUMA >>> from the start. Hence no point in carrying old baggage and obsolete = names. >>=20 >> This patch adds it; do you suggest to redefine vrealloc_noprof() to = take align >> and nid? If we don't mind being inconsistent with krealloc_noprof() = and >> kvrealloc_noprof() that's fine I guess. >>=20 >> FWIW, I prefer consistency. >=20 > What inconsistency are you talking about? That > krealloc_noprof(const void *p, size_t new_size, gfp_t flags) > and > vrealloc_noprof(const void *p, size_t size, unsigned long align, > gfp_t flags, int node) > have different number of arguments?! >=20 > See: > alloc_pages_noprof(gfp_t gfp, unsigned int order); > __alloc_pages_noprof(gfp_t gfp, unsigned int order, int preferred_nid, > nodemask_t *nodemask); >=20 > Adding double underscore to keep all existing callers of > vrealloc_noprof() without changes and do: >=20 > vrealloc_noprof(const void *p, size_t size, gfp_t flags); > __vrealloc_noprof(const void *p, size_t size, unsigned long align, > gfp_t flags, int node); >=20 > is fine and consistent with how things were done in the past, > but adding "_node_align_" to the function name and code churn to all > callsites is a cargo cult. >=20 I see your point but your approach is currently only applicable to = vmalloc and it will not work for slub because the latter already has = __kmalloc_node, __kvmalloc_node etc. and we want to keep at least some = naming consistency between k[v]* and v* functions. This whole patchset is only intended to add the capability to set node = and properly handle alignment requests in Rust allocators, and is thus = well aligned with your idea that the new code must support NUMA (which I = do share). I would suggest that we get this in as it is, and then I can = take the burden of straightening out the naming which will inevitably = lead to many modifications in other parts of the kernel. The latter I am = fine with, too, but not in this series. ~Vitaly=