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 A18FAC369C2 for ; Wed, 23 Apr 2025 01:17:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC11D6B0008; Tue, 22 Apr 2025 21:17:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A6FE06B000A; Tue, 22 Apr 2025 21:17:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9376C6B000C; Tue, 22 Apr 2025 21:17:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 74D7E6B0008 for ; Tue, 22 Apr 2025 21:17:56 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 86B8314271C for ; Wed, 23 Apr 2025 01:17:57 +0000 (UTC) X-FDA: 83363546994.21.AEA0227 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf26.hostedemail.com (Postfix) with ESMTP id 12F68140003 for ; Wed, 23 Apr 2025 01:17:55 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="a2/2xe3W"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of dennis@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dennis@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745371076; a=rsa-sha256; cv=none; b=KgrbHhp6WaT7lnU+UJh8W6QTVwVybaUOSIKP7xAzc83qNfQvV+kHXTiPgbR8y0pM90TXeE EIlJLDBoOfcE6CcpneGLlwY4fjb6Hk1b4i9D1x9Ya1OEidtzKqDMFpyDOzEhYy2H0c0Fi4 rWzH0eTvaTbqFMhfkXr9bwQS7zgV+Ko= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="a2/2xe3W"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf26.hostedemail.com: domain of dennis@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dennis@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745371076; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KxZ0aOqX69qxk33vE89XVo2A26UBv9BmA9RXPJdbf+Q=; b=0gWHrbJtPjwp8G8HvB08Ip8fhgG9b1h+OeALFPP+8sXhc+Sl6+S0uTQBnpEWJ7isCRpHRr yzRqoEnh5lHWgRhXW1DXVahFMTwSdsbDJMhEHc48sqEWPn/vR6pH56pvo7wKXEP64F0SjQ /ek5HpdjPtS+8jjfLyIUgYujAMGF8T0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1902B5C490A; Wed, 23 Apr 2025 01:15:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 37D61C4CEE9; Wed, 23 Apr 2025 01:17:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745371074; bh=Zylnpb2TEmbMQh5WC0vsdH2I+J9na/9RUwBuAp0YScE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a2/2xe3WFytGgxOnWjC+Er9KJ4V2acrQ/2OFwTsINq50VN/MkTk1ge6H6Fq0gaEtp 302ejpCSGFofo//ErRRv0kAeH3xzjqcIv2Qnx6Jt1Iov8SegtAeq2sUNMln1AKKGTp UtlEa5L19MB2X0iXhtH/94Dm1Qv10bIftdxSIz5t3/wQ7UygZwUxNS8OjkbZRzD8w3 Q95LYwjI8qk3TGQJ6hwNW1ATZrJ9/sjcrlM7jX3XTqqzoN10oHSwqt3LFTCGhbCGVl QJBOsR51TFoyUrOHsDDheKMZld6TQq1Uc2/sp4ET0RaGeeITM9IHU76uE1zi87kk3s rZlmc6Jt4oBoA== Date: Tue, 22 Apr 2025 18:17:52 -0700 From: Dennis Zhou To: Andrew Morton Cc: gaoxu , Tejun Heo , Christoph Lameter , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "surenb@google.com" , yipengxiang Subject: Re: mm: percpu: increase PERCPU_MODULE_RESERVE to avoid allocation failure Message-ID: References: <20250422170209.a8beaa8a3610d2e92421476f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250422170209.a8beaa8a3610d2e92421476f@linux-foundation.org> X-Rspamd-Queue-Id: 12F68140003 X-Stat-Signature: bdw5aydu5q6bw6i3h5xbuwhdcin44cai X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1745371075-229162 X-HE-Meta: U2FsdGVkX1+0c63dcgDrBmvlxEOoytzVVPwfIsJ7pd9JtUoapIlVpqLLfageG/GYRnhbftBGhDHmBm+OaBtKqNBmD9fTSFA92GU9TIMKr8Ix30JOMTOnTT2NS6dRVw8Z7g0/vZqcXpS+QAwguRxiEoky2RqvBn+QQ2WsiM3hQZogksrvlhQGo1fG9/1L0PfaZ/jHNcAmOIHGZrn3++xEWkBmRcNUGzTMRSrQU1w25ycvB59VJyWgI4/r9Igg47M220mkk7B7NX7uRrDHLCiteEi8OGr7739toIyRzQy6YzpfPh+h0VawMAFVCNkdOle1+4PIXlrKo2EaHSKWY+qiAQgumkZWDVYUDc2p8j6QKv1zqJtDCk3QRNBrDv4tuCchRiabgl7nrHFsaCGWEQ2DL5chx8dpyTJkUclBXmb9nTZMiJNKJzdOfKmYj0DhMOoIhFbV9VEVAiVjy2L5nXu2szNa+RoIg3ttxAgU7AMA7uDdTErFcy9z37jwDE02qak60H4ngchXxNOkudmA5oU2ktsbJc/GCbWIY5Z+BadpWo7gfuoubPann0H1w+/0CDNcLpVsEfsUidsb9EyBF9/QxcBKydvhhtFB4cBSQ5cV+Cm89xWoL0r9IPfiyLVeAheXcwsUQuLmYUOKkLiXqB7T6W30J0IUA4r0FG3TzvctNcB6Ka5VZU+oTKnfPlwLsKeAV8Va2ffCT5TJqTDbFcgpd6XAGwOMe40jdACjrJYvLnc99fX1ZREf6dPLU0uH895PlV5hKJJxifUmxudJ/wcSa//rJ3kaW06ZFZ6/Ls7Kk3sXAs1dC0/9QnXDfC19y+zY9hlEBp76aWrQqnLPAXGorEg9JiQzAQ67H0qn19KFRmeQ9EYUCxcyO1fBG4l2Nj7YfoacYt+FcUHmu/Lf0/rNybPX3ydc/CDapoxV8jJE1XLRYkrRTAV8Zlu+gdsmStB8kjVozpdzS42CZufKubt FXWlA3VZ 3jjxU1sZw9aQr2OFvx9ffpRAIsZFvi1gmjOrHGr5Y9PX9Dug= 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: Hi Andrew, On Tue, Apr 22, 2025 at 05:02:09PM -0700, Andrew Morton wrote: > On Tue, 22 Apr 2025 11:39:30 +0000 gaoxu wrote: > > > In android16-6.12, enabling CONFIG_MEM_ALLOC_PROFILING causes some modules > > to fail to load during boot because of failed percpu memory allocation. > > Which modules? If they're in-tree modules then we should fix this > issue in -stable kernels also. > > If they're out-of-tree modules then what argument is there for altering > the mainline kernel? > > > [811:modprobe]percpu: allocation failed, size=5200 align=8 atomic=0, alloc > > from reserved chunk failed > > [811:modprobe]Call trace: > > [811:modprobe] dump_backtrace+0xfc/0x17c > > [811:modprobe] show_stack+0x18/0x28 > > [811:modprobe] dump_stack_lvl+0x40/0xc0 > > [811:modprobe] dump_stack+0x18/0x24 > > [811:modprobe] pcpu_alloc_noprof+0x96c/0xb58 > > [811:modprobe] percpu_modalloc+0x50/0xec > > [811:modprobe] load_module+0x1158/0x153c > > [811:modprobe] __arm64_sys_finit_module+0x23c/0x340 > > [811:modprobe] invoke_syscall+0x58/0x10c > > [811:modprobe] el0_svc_common+0xa8/0xdc > > [811:modprobe] do_el0_svc+0x1c/0x28 > > [811:modprobe] el0_svc+0x40/0x90 > > [811:modprobe] el0t_64_sync_handler+0x70/0xbc > > [811:modprobe] el0t_64_sync+0x1a8/0x1ac > > [811:modprobe]ipam: Could not allocate 5200 bytes percpu data > > > > Increase PERCPU_MODULE_RESERVE to resolve this issue. > > > > ... > > > > --- a/include/linux/percpu.h > > +++ b/include/linux/percpu.h > > @@ -16,7 +16,7 @@ > > /* enough to cover all DEFINE_PER_CPUs in modules */ > > #ifdef CONFIG_MODULES > > #ifdef CONFIG_MEM_ALLOC_PROFILING > > -#define PERCPU_MODULE_RESERVE (8 << 13) > > +#define PERCPU_MODULE_RESERVE (8 << 14) > > #else > > #define PERCPU_MODULE_RESERVE (8 << 10) > > #endif > > PERCPU_MODULE_RESERVE is a pretty unpleasant thing. It appears that it > gives us the choice between either wasting memory or failing module > loading. But I expect that something more dynamic would be a ton of work. >From Tj's commit back in 2009... 6b19b0c24004 +/* + * On x86_64 symbols referenced from code should be reachable using + * 32bit relocations. Reserve space for static percpu variables in + * modules so that they are always served from the first chunk which + * is located at the percpu segment base. On x86_32, anything can + * address anywhere. No need to reserve space in the first chunk. + */ I'm not too sure where our x86_64 32 bit support is. If that is no longer true then we can likely fold the reserved region back into the dynamic region. Given the above, there's not really an opportunity to do this after the system has booted hence why it's baked into the first chunk. Thanks, Dennis