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 E8517C369C2 for ; Wed, 23 Apr 2025 00:19:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 321F86B0005; Tue, 22 Apr 2025 20:19:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2D0896B0007; Tue, 22 Apr 2025 20:19:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BE406B0008; Tue, 22 Apr 2025 20:19:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F1D716B0005 for ; Tue, 22 Apr 2025 20:19:44 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9754BBA4D6 for ; Wed, 23 Apr 2025 00:19:45 +0000 (UTC) X-FDA: 83363400330.21.715385E Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf17.hostedemail.com (Postfix) with ESMTP id E7D4640004 for ; Wed, 23 Apr 2025 00:19:43 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="qOC15t/B"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745367583; a=rsa-sha256; cv=none; b=SPFIUJQpYF5lIe3kdWDiqn3zDhNkUAeRC9/PydVZD3u2jq8GkkFeWp94bpIT69BwN231mc kaPtlFCVdIks+igrjDM6vg5CErzXBw7+QqHYsVSPIKu13CP0rh+OU6iDp8S6KO6QX6PPdH KMjG/vtHqWBH7vR+Gp4P1YraBwmTZZM= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="qOC15t/B"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745367583; 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=H3No/2dtu0+LXKUdzwtUjJdhYkwOoEuO1odhuEfxBQU=; b=M6g2Jlo+pV9Km+qUtU13UB7k2GFPzzuglwXYv2gBijp0HnzH9t68UIieJ9nv1Me8Ckbg1B fEuY6ypW15FK4O+isdugklBclQWOliNJUnFJa2j0AT9WJJ+h8Xw4t/se3qkRPlgsSI4nSX 5Ddk4k1OCSRMigpPrVcqrj3kkG40Z3c= Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-47681dba807so65891cf.1 for ; Tue, 22 Apr 2025 17:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745367583; x=1745972383; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=H3No/2dtu0+LXKUdzwtUjJdhYkwOoEuO1odhuEfxBQU=; b=qOC15t/BBym4KSFyO0P+vmeY2beYLSxoXOTkVqI0fUhP616KAsR66GXokAMCT4DW9B jRrNT7nT+s25Zbx3Sii4SJH3D8X1hgBJJuumWGebChts/W8Xa5McMPeqGnrtfgagr2e4 BJcHl3f3U9ThNzDgsh+xbUqxXQcMaQtOq0duU6LdI+mVSYanjlyUylMKEIRKDxOOXzAF qiK5pthCk1fKkQEN9Q8/8PP/pf7cAKlLtIQmdNJP6s/j6KuCdgD4rjhe/O8lHHTImiwq BtsSGJCVX7LZeFU9mA2pSMBtGoyPCcz6RFc6lLALCjJzXAtQz/hAyVaqw+vJZ/Ct1CxT 3J9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745367583; x=1745972383; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=H3No/2dtu0+LXKUdzwtUjJdhYkwOoEuO1odhuEfxBQU=; b=wYtVya+hUNtdoxOPvtoRQb3wGkpktMVaUytN8Hu8Pt61roGrPfQdeYlZu/nC/R2ug4 y3ALdMlQjUt6sTfKh1ajOnNYMuYdoiG2b8ky3P8Ydps39jWzbJMxXNUSoFnleBukjdS6 IwuQ2vFT0Uyr4s6REQO20VuDwWZB6y8D8DdulXnzHhsi7WpkyxfwUrJIykgeq/oxIn4h 34+iXHKUQrbqygJi4ZvnT2DF0rYQjxBq1WUlPmn2Ncy7nJTXlojY5i+EstgHEwNj0vJA YXpaHw1qsAsgeXRuE7QF4VB4kbcIlQm7R1Tsa3wzVQhCWfz/84A3kXWFwdu2Ecpj8O/x qBvA== X-Forwarded-Encrypted: i=1; AJvYcCVIJ+YVdtbDn47Lf2jwCWL6DRTFno4xtxKh8HuKIojzcYtFR3eCgU6kfAUkVzY+hAjr0vQ65jcpdA==@kvack.org X-Gm-Message-State: AOJu0YxZVXuGwTq5iPiNx727PgBWAHX/6/h2l1uFeSx6Q9+bOD6z6cpG E9T7WL/wvbx9Wu0Ltpw+nBdcfSPW45Rk7EP6MuZYU4qjuarXcx0bY2QnomQUe1UfnIdRe2pt14y xv63PCFbUQcCFIQPtBM8kdGnMTjBinkEsIsNL X-Gm-Gg: ASbGncuepgj9Oc63ilGKc0jterdpdsuZS9wNXmJUUUVqgxfvueyiVjSw4eYxwoTcjPE c/24t2VsDU/4MRzhtLpQ0xZvWhLsB8l2xNLq5ktDxcIPpX3fJ6lvLfviV51lMjp1EGjED/2xZL/ 4qA1LR+nANUUi2xe/+KvQcZIbsJPkaw62TMhsckUSUe0ThoKZYzUggN1wtMzawCAc= X-Google-Smtp-Source: AGHT+IH7IorgCmV+iTHjEMuegFoDGcglumG/XFNa/8Q0aSWzo413n+eMzU+6LX09zNqmBYpuTFc45XT/cHmnWQol8zM= X-Received: by 2002:a05:622a:5106:b0:477:1f57:5493 with SMTP id d75a77b69052e-47d139f00e8mr1861481cf.20.1745367582741; Tue, 22 Apr 2025 17:19:42 -0700 (PDT) MIME-Version: 1.0 References: <20250422170209.a8beaa8a3610d2e92421476f@linux-foundation.org> In-Reply-To: <20250422170209.a8beaa8a3610d2e92421476f@linux-foundation.org> From: Suren Baghdasaryan Date: Tue, 22 Apr 2025 17:19:31 -0700 X-Gm-Features: ATxdqUHmT4ZISXhJZbUGDnKoBch92eAZqzRFMlN3Azi0veRBlQYlRe8wECJBt5g Message-ID: Subject: Re: mm: percpu: increase PERCPU_MODULE_RESERVE to avoid allocation failure To: Andrew Morton Cc: gaoxu , Dennis Zhou , Tejun Heo , Christoph Lameter , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , yipengxiang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E7D4640004 X-Stat-Signature: 95sh4ryaedgc79bdmubdh3eri3smdbxs X-HE-Tag: 1745367583-167505 X-HE-Meta: U2FsdGVkX193/iDSOGHyvRu3uLJ/7xvpXndI7jmGUNoReX12T4KgksWr2xUYLAQ3TuYQgX4tFSFRe8Ca7hjhzlSzb60+Q6bWgOLcnrDZJVSq6lLd1nloZU+DXmB/LF5S0g2oGxZTbSW7g9Ct0ZNxpnhzxkymYP3LuujTHmdAwcYFKyxefRU6+q/SAmkeJHJNDfiirhwcLM7CngF0DxmVtEEtuyfcLYqRXlTt9cMOkqR7ECucd0gohnnmD4ybRswJ98x7ci/bfHaCJ3POi+hFq1buean8ghK6jCXdf0xSAgeQb7hv9HaqQBH0LeVGAx+cdCGxbxPpmWRTgIYlNVZJr/OwI9aXJ+KmfCn7MAlFgkkMXlg3B6WOOX1YBPEHb6svOOLIWlTIDmQ+zJTlw0ibTj74EPWLbhz7HhcT8jJ64LYU6Zvh+Za1HRJkT9TWA8zd64nKhTmA5Q2lGxESQdMhXBJ4AM8an1iQxwWXewU5g+pNwB+eg80F+eP7Wwa9yPKJyaJwzoWk7Gmq40UzjoVWZTvRDMTtbv6Uo03ws/bzZcpnrjiu46R8Hrklv7p3kDalMy0RumKamsDCTd4P7SUm7ywJxQrIMByPvjtpZwjIdnHCFAqIgBEu7NjOSpq+GBvMH8DCISrjh+yruZNPJZsq+KfpzEAn35thAjdkNjtFsSdIIm/PzaAARfdXQm3rlJOTr8TJZ6SCCpxjvvoP+m8s3pG/qFNNOE/MkuI8RALENGPbYtfVm1gtFVIjfU/0Gu60F5Htp3mXYwbgmQC32uoUT048jqyPrr3piEC4r94lnOa201tRNDOiTEq3SfsnJ3eH2I17hNnkQutsuOjimx3ebXkMX5yTIrwgtTrtpCbsPsiGshQcao9oCTUAxtaCP4NAwyeOJoZvIjHGiAqU1PA1EloJCD29Bm2gi1hlmwIisUm1XqaV8ADNpeZqdVU58B0rnFqIrpSj67sUsKbUArb QVOPON+x tmPjEDALEM5ZHOOCDU4a/PUkiFQ== 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, Apr 22, 2025 at 5:02=E2=80=AFPM 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 modu= les > > 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? These are most likely out-of-tree modules from an Android partner. > > > [811:modprobe]percpu: allocation failed, size=3D5200 align=3D8 atomic= =3D0, 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= . Allocating this reserved area dynamically would be ideal. OTOH this change increases the area size from 64kb to 128kb. Don't know how much effort we should put into it.