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 5BBB2C71136 for ; Thu, 12 Jun 2025 01:39:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8C4F56B007B; Wed, 11 Jun 2025 21:39:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 875066B0088; Wed, 11 Jun 2025 21:39:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 78AB16B0089; Wed, 11 Jun 2025 21:39:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5C7916B007B for ; Wed, 11 Jun 2025 21:39:34 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id AF11FBF8F8 for ; Thu, 12 Jun 2025 01:39:33 +0000 (UTC) X-FDA: 83545041426.16.205BBAF Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) by imf24.hostedemail.com (Postfix) with ESMTP id ABF9C180004 for ; Thu, 12 Jun 2025 01:39:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ljxM02K0; spf=pass (imf24.hostedemail.com: domain of hao.ge@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=hao.ge@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749692372; 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=fDaLoebKXYq1dhWh0U4LSCfiXioc71GWbSJENfRMRds=; b=zQs/CQn+FB7ysfOTYo/mhRPeqqCNqxqmW5MqJij/TPiKrdkOq5tKOelWs5b7bvPkByWHT9 QRZyQHdO5Gmqq++XX9xx7YQxEYqDBoxP//hq1woX1XqdZapUaxWj6fFcr3RkRgvi/nsgw/ iQCgD7jeZtkWxX0EFmCPtjGWXQuriVI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749692372; a=rsa-sha256; cv=none; b=7/ZLpYnh7HlOBARrKFQAbOGba7ogotC+upIR/K7s4eg5L70SW1LAPNnaD0qrzeXyuRI+rG 8fI1Q0u/BeVj8a94ETCpgSKBEF67mt4YKy1SqDGDcK9ugrzx7UYjrA473u76aKlpfKoKDa pL2zLW0RqKEizMN9rDs3XUBKOV0GBhY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=ljxM02K0; spf=pass (imf24.hostedemail.com: domain of hao.ge@linux.dev designates 91.218.175.171 as permitted sender) smtp.mailfrom=hao.ge@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1749692368; h=from:from: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; bh=fDaLoebKXYq1dhWh0U4LSCfiXioc71GWbSJENfRMRds=; b=ljxM02K01UuAJs38k0Uj76PvRaegxhg+IoFOPX7g5cdn2lv8wy7HbvFZNTYpQlHIbKTywn TfibyxnagfDXkXUhocJ3w5iUj67ZpqapaQZY6XfVcs0tP8kofRXslDVVmqudq9/zHTJR1d 7uifdhIuKTKINZXxppt+VsC3TJrnBNQ= Date: Thu, 12 Jun 2025 09:38:47 +0800 MIME-Version: 1.0 Subject: Re: [PATCH] mm/alloc_tag: add the ARCH_NEEDS_WEAK_PER_CPU macro when statically defining the percpu variable alloc_tag_counters. To: Suren Baghdasaryan Cc: Andrew Morton , Kent Overstreet , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hao Ge References: <20250529073537.563107-1-hao.ge@linux.dev> <177e1f6b-50f0-4c0a-bb0b-514283e009a2@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Hao Ge In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: ABF9C180004 X-Stat-Signature: nak1nf57wrnqqcuspcz3kdwqr7sn1paq X-Rspamd-Server: rspam04 X-HE-Tag: 1749692371-217550 X-HE-Meta: U2FsdGVkX1/9jojmasGPDPqhCgO2C7uUlNGhMJpuSa53yKsqXJiS1pE24YeLemSOCJXQzcAW1b7A6jYFeLWRYf5uiLooPxKzC2NnEDI2vBqm8nSbRcsSiOS7yRKaWXxpIVIvHN7AoIx2Kn79u8jGsP2iLN6bxegijWKvna6a+CHja5BnwOorLX8wQCqgkrt/R5FiISypF3HaRi+xxU1ObtR4Al9R0MAgPe9x4tYFKWuB29T3XARoMrwRxVrh8ZrPcNtX5oWDTVjOLr3FCdTg6DHCvMwcbYpgwNHLLr4VpdyZYp2nFlcMX7SWodfDAzvXWj1poMgd7PWNQRbmDPffWN3RioR9SQVoxykEhLWIZ7NvJOB0ckOqPhyvd41qFIA+QA1VMFCJBYHu/kFne0T0NH5m6+2iOWmrBVLs/sUNk+g/T6R6R0f5rcagXeue5b55grlOlx0lRaXKBRUP5eLgXpndlDDJqwVia93vJq9UGEQnHvCSCCsJqEBBW0Lx8NBZGq6yK0XL+3J+dri/sjUWuHHveVK+DAGLo3BLKIuW7IaHJHT6SGnUufdRaBRXyA/4fixbxb5/cJX5Ty22rB6RLIZnRVD4DWbdwTRkRap6/15KZc4MaskI5HxeuNx26qcbAhDXAbrN1GKUVPopdbttYKe+YA6CMRLz4l4Z/zvcC6vj4bw7nPOlYF8y8Ytz2sapH0Y9QRqLZi8+K1fMQirtWaEHWepDI1xnWE8u5GCf8VZEGQfSULzvkK3tELmloedUZYteIjXN6nmfZnR/D5yRf02caNH5zLLoSJYXEHlEMMU/RrBTh3cX9al/qZAtfYAvaj/fRnUfrYohezxzl+HLP1taNLQ++HF566K3UWM7tE3jq7XEAgCgN3v2J7wlySBU5dm0lEn9CqG+MfY10b3A0InOA8jCz8djXbQmaM8cusCaTFS72q1PUmaBqQBR7xSh3ozv9eJKaB5lHUJt8lv mlwMFARB xHSmiSJOS36UGCWT9l3ZFOYHnPN9jdgRTOe8XozoolSxDHd3Zz553N9xZUs98LuU5q+l+UUTqSAJhYhJeF0Nui5Tm2W/8IYw5TF/Gjwy33gP42GN/LOiFr0b37/BNw9r7ZXzj+hhigcnJaGCsRsFbSb30BIwW0oPTw9tRrgHSDVHqPOzHiKqYsFmymAQnIWEzQdtJYtIWmWuW3qnRfc3v2tfhANtnZpEDYFFJfeGMa22s/AWIcXApbDiboWZ5Brxz92V60PHiDrZpi37w6G8G+KhftG7uY6NRZJVNPl7VyVFM0/K/2nb9KyiVdqgs6XL3agTiBfd1MaQtkIqBC33D0XK+3L16spBgCK8GJrZ8M2QeyuAQ0X+Q7G8movOggL4GQpvchK4Bcb9OtYY= 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 2025/6/11 23:24, Suren Baghdasaryan wrote: > On Tue, Jun 10, 2025 at 10:27 PM Hao Ge wrote: >> >> On 2025/6/10 00:39, Suren Baghdasaryan wrote: >>> On Sun, Jun 8, 2025 at 11:08 PM Hao Ge wrote: >>>> On 2025/5/29 15:35, Hao Ge wrote: >>>>> From: Hao Ge >>>>> >>>>> Recently discovered this entry while checking kallsyms on ARM64: >>>>> ffff800083e509c0 D _shared_alloc_tag >>>>> >>>>> If ARCH_NEEDS_WEAK_PER_CPU is not defined,there's no need to statically >>>>> define the percpu variable alloc_tag_counters. >>>>> >>>>> Therefore,add therelevant macro guards at the appropriate location. >>>>> >>>>> Fixes: 22d407b164ff ("lib: add allocation tagging support for memory allocation profiling") >>>>> Signed-off-by: Hao Ge >>>>> --- >>>>> lib/alloc_tag.c | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/lib/alloc_tag.c b/lib/alloc_tag.c >>>>> index c7f602fa7b23..d1dab80b70ad 100644 >>>>> --- a/lib/alloc_tag.c >>>>> +++ b/lib/alloc_tag.c >>>>> @@ -24,8 +24,10 @@ static bool mem_profiling_support; >>>>> >>>>> static struct codetag_type *alloc_tag_cttype; >>>>> >>>>> +#ifdef ARCH_NEEDS_WEAK_PER_CPU >>>>> DEFINE_PER_CPU(struct alloc_tag_counters, _shared_alloc_tag); >>>>> EXPORT_SYMBOL(_shared_alloc_tag); >>>>> +#endif /* ARCH_NEEDS_WEAK_PER_CPU */ >>>>> >>>>> DEFINE_STATIC_KEY_MAYBE(CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT, >>>>> mem_alloc_profiling_key); >>>> Hi Suren >>>> >>>> >>>> I'm sorry to bother you. As mentioned in my commit message, >>>> >>>> in fact, on the ARM64 architecture, the _shared_alloc_tag percpu >>>> variable is not needed. >>>> >>>> In my understanding, it will create a copy for each CPU. >>>> >>>> The alloc_tag_counters variable will occupy 16 bytes, >>>> >>>> and as the number of CPUs increases, more and more memory will be wasted >>>> in this segment. >>>> >>>> I realized that this modification was a mistake. It resulted in a build >>>> error, and the link is as follows: >>>> >>>> https://lore.kernel.org/all/202506080448.KWN8arrX-lkp@intel.com/ >>>> >>>> After I studied the comments of DECLARE_PER_CPU_SECTION, I roughly >>>> understood why this is the case. >>>> >>>> But so far, I haven't come up with a good way to solve this problem. Do >>>> you have any suggestions? >>> Hi Hao, >>> The problem here is that ARCH_NEEDS_WEAK_PER_CPU is not a Kconfig >>> option, it gets defined only on 2 architectures and only when building >>> modules here https://elixir.bootlin.com/linux/v6.15.1/source/arch/alpha/include/asm/percpu.h#L14 >>> and here https://elixir.bootlin.com/linux/v6.15.1/source/arch/s390/include/asm/percpu.h#L21. >>> A nicer way to deal with that is to make if a Kconfig option which is >>> enabled only for alpha and s390 and then do something like this: >>> >>> #if defined(MODULE) && defined(ARCH_NEEDS_WEAK_PER_CPU) >>> #define MODULE_NEEDS_WEAK_PER_CPU >>> #endif >>> >>> and change all the usages of ARCH_NEEDS_WEAK_PER_CPU with >>> MODULE_NEEDS_WEAK_PER_CPU. >>> Did I explain the idea clearly? >>> Thanks, >>> Suren. >>> >> Hi Suren > Hi Hao, > >> Thanks for your guidance. >> I understand this train of thought. >> >> I've been thinking about a problem: I only added the >> ARCH_NEEDS_WEAK_PER_CPU >> >> macro to isolate the definition of _shared_alloc_tag. >> >> Since s390 defines this macro, why did this build error occur? Hi Suren > The problem is that ARCH_NEEDS_WEAK_PER_CPU is not a Kconfig option, > it's just a definition, for s390 it's here: > https://elixir.bootlin.com/linux/v6.15.1/source/arch/s390/include/asm/percpu.h#L21 > So, even for s390 if you are building core kernel code (not a module), > ARCH_NEEDS_WEAK_PER_CPU will be undefined, however if you are building > a module on s390 then it is defined. So, your change effectively > results in _shared_alloc_tag being compiled out in the core kernel > while it's used when you build a module. Therefore during linking > modules can't link to that symbol in the core kernel. Hope this > explains the issue. Thank you so, so, so much! I understand now, and thank you for such a detailed explanation. > The way I would fix this is by making ARCH_NEEDS_WEAK_PER_CPU a > Kconfig option and enable it for s390 and alpha, would replace old > definitions from > https://elixir.bootlin.com/linux/v6.15.1/source/arch/s390/include/asm/percpu.h#L21 > and https://elixir.bootlin.com/linux/v6.15.1/source/arch/alpha/include/asm/percpu.h#L14 > with: > > #if defined(MODULE) && defined(ARCH_NEEDS_WEAK_PER_CPU) > #define MODULE_NEEDS_WEAK_PER_CPU > #endif > > Then use MODULE_NEEDS_WEAK_PER_CPU instead of ARCH_NEEDS_WEAK_PER_CPU > in all the current places in the kernel code. Lastly, to compile out > _shared_alloc_tag your current patch should work fine because on s390 > and alpha ARCH_NEEDS_WEAK_PER_CPU will be defined after all these > changes. > Does that make sense? I quite agree with this approach. Thanks Best Regards Hao >> Could you please help explain it again? >> >> Thanks >> Best Regards >> Hao >> >>>> Thanks >>>> >>>> Best Regards >>>> >>>> Hao >>>> >>>> >>>> >>>>