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 5D37BC369D1 for ; Wed, 23 Apr 2025 17:04:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6D8616B002C; Wed, 23 Apr 2025 13:04:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 688416B002D; Wed, 23 Apr 2025 13:04:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 576126B002F; Wed, 23 Apr 2025 13:04:23 -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 3B31C6B002C for ; Wed, 23 Apr 2025 13:04:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 2E2681A15E4 for ; Wed, 23 Apr 2025 17:04:23 +0000 (UTC) X-FDA: 83365932006.22.06FD302 Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf17.hostedemail.com (Postfix) with ESMTP id 51A2D4000F for ; Wed, 23 Apr 2025 17:04:21 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G1zWOmVr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745427861; a=rsa-sha256; cv=none; b=diSbUcKX71+82ZhS6Co5cpG1oXBTdErhPJVGgVUkW9r6TZG0Lb4eHysXct5LdKBHIKZuCO ub9k68iyWJo+YLFONr9GJeMsYU9XmpYEp4f7/y0j3mE6cyELO8ZU0ZOuEStVloHkawe/Lx pLVMscz3hjPDLIaiKZ33WNcDzKtcKFQ= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=G1zWOmVr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf17.hostedemail.com: domain of surenb@google.com designates 209.85.160.181 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=1745427861; 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=4T78alXt/iIwXp78tg/kPkO/5eMQaCbSQmkPu/StvNk=; b=pzJ8EZ8luaUlkwv0BYalHo6CD2yK0Qvcx/cS/QjgMuSMZWlUzK2Mu+4XeeXSJGpN3GoTtX geqOqGaAvNOwXxARoJQwQkTQ4SL4Q+ZlteD/5KcNRXYW9GSjaCMafFwh+/tieY4J5KvZ7C nsdeNjunp70/2ealQ2hmaPn+HdJnwpc= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-47666573242so22531cf.0 for ; Wed, 23 Apr 2025 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745427860; x=1746032660; 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=4T78alXt/iIwXp78tg/kPkO/5eMQaCbSQmkPu/StvNk=; b=G1zWOmVrb96pffPaZ14/IeBjrX73MWQd6OQAuMfbggGhIUlqDDN6yViiU+wSdrnfNH 6w+ayrzAMmqJJEObJqbiQgiCNpv2+7Efl2VfIQUE48aBHQT/WJL5B6ksRmEGWiOA5Neq eLQWw0s07YYE0DT6XkyLB8TNZ91/eZ55yvhhJgqmTCnU27lN4iRD6jUktt88PgNp+D3B Yo1q2VJlix3KX53ha40bwYBuUcfvrPfOjbCtYlmfikoEpzf89Vd+I7WFGfHwVBhA8eG2 HKnjaOY2OFj9g4tf2bwr7a2LNY+wczEsrRpkEwSpvrIyx4fJx/5WwiLz6+akIWsYnJFM L9Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745427860; x=1746032660; 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=4T78alXt/iIwXp78tg/kPkO/5eMQaCbSQmkPu/StvNk=; b=FxD61E/ucYW85QZiP3tCr05sY7t7SbNnz+y4dTenVMwmUdnX0Xg1Pzbib0i2EZdWYG miMFn2GFrVNNgGfsSPzXFcL+sDleBue3IfL0emN41tsSxQiVDvELC60ppnI9T8LEkx1u mxPxpSvn3ualiec8NYGDnF+vQhOvNX34ceOY0zWrXT0oiNwPoNRUFRVAuMjSmkss6I+c Q2OynfJrvPAPXfuCGQ4vW74ZWoVvk92iH4/9BRjKdRtAEY6ZswkjPz71GA5z213DwifH NiBa3ur1MCslSoDcHjndAySSGFqNVsAxT6mRRbWfE40PlYayc7V2n9ME/GhbG9Wf02iq mKFg== X-Forwarded-Encrypted: i=1; AJvYcCW/Id/V7IdU6eX5wYLqLoaSO3Ll6otjgjWEud4ga5ZEZbQQIJMtIHTO5XqtGGWncAe9DcztyC5Szg==@kvack.org X-Gm-Message-State: AOJu0Yzq1G9xVOvcVfuGJrNzDRbfRMSm8FAG4KG5ibdF7GjdAhQR9ya+ MST7rja7UGjHhtr7W5uwU04R4eyjtCaLype2QH4QggQ4ahmlVKlrqZNc0mnfSLcA0MYhnYZMcj0 v2RfOmjGHCA/QlFWBg8EZdBeI2k+rluA8ZaKfeZtTDGxdFVqgmG0Y X-Gm-Gg: ASbGnctttE/KB3pDO/0qxNY5JL5KXdMnlwva503JUKcT/1A0SiG0VrIozRUTE9e1Nwj RrLiLVS/kcxP0sB1HJCphjy8Jh0/tcmSqca28Vm7aT7amVDWKZVXTwAFJrreUq6mn6FQevaFMZq dbVNSYmMc8ZY+rTP5D/UguL2sX0J+VvUaYiGsY/ei+D7YKSw9eeMSv X-Google-Smtp-Source: AGHT+IHfwTdYoSufLjSJ58LqZBhkAkdFx/ssz56U94sPn0nQbStE/Va0flBY27HFgzAD7B7hO4D1JmbA5Qx0DPk6l+I= X-Received: by 2002:a05:622a:5a85:b0:479:1958:d81a with SMTP id d75a77b69052e-47d11cdfed8mr5784911cf.6.1745427860136; Wed, 23 Apr 2025 10:04:20 -0700 (PDT) MIME-Version: 1.0 References: <20250422170209.a8beaa8a3610d2e92421476f@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 23 Apr 2025 10:04:09 -0700 X-Gm-Features: ATxdqUHJ30i9OLvtE2fA9LHY6wYiUe30eXJDWxJRdsQ2iAe3qRdieefkGhz3J4A Message-ID: Subject: Re: mm: percpu: increase PERCPU_MODULE_RESERVE to avoid allocation failure To: Tejun Heo Cc: Andrew Morton , gaoxu , Dennis Zhou , 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-Queue-Id: 51A2D4000F X-Rspamd-Server: rspam04 X-Stat-Signature: rh6jf61c35ftck3otsfgw3dhdbza3t13 X-HE-Tag: 1745427861-392782 X-HE-Meta: U2FsdGVkX1/qtSQ2x7d8VyROgSOvajgvDdhIoczxPwfBpRBS8e83+OH7Wspye+g/LFIC5kZGa/xDsd7kAxdSbaZR7r3AxVWnpuBLCrRYFhinPBLMp+exqi+o0wUyS/1ZdxiqoiAyxNTym33+MqWifMhkyg5AGUl193bCqUvF+qptM2wokhjqx6uS9pOpSPghO9zCHuzfn5ZCi8HDuwrj0intLH/8/zD7l7XSZwCXitB29Osve2hukpUywnCiXd7gNh4Lv0OhMxBOIvmlCgo0SnufAOauMf17PgzUkcFykSbkttQvL740M6G6ZIbWzZEc8A0PCODhgqq3+1CI41MjD69VK6RpSgZ1zJMVsKxyilAPPSULFG2E5py1sgXxcLpchgVTlkYfedQt7jQ2u0rCHfsrL50v5vNf0nbjnz4/edeu092bP1Vwm6vj1orghDdG8lAZ1CJMEKoilfPo8r9AThyEmT925s1qHeOWf+Wt15tnVvqcyYSjlPtO1DrK1h3s6zMeICE/eDp/dJYCWj23rkLAryDYThJhyiAdDYvjmvgNKxNZT/n288tUoagZNLnSPjS+7SUggxm22gPeLKxzZTFxUOYOseweSE0jZNL+Kt/xBG2FrtR35yjGC239u+E8rQ5D/VkxI2owx61/SIQopldTn+uoKSpx/djep9UgiOh4+tDW60uD8CVL+5lEy+A58NjMHEo3Lz2RtgkTpfqpUzzRXj74rZsByjR4c8nPH8laAKWRGrHXPKWpLR4WyOEzu0+sVxKcL1Ng96m1LT+NDe+UpIOwxN2lpU6iJrOH2e7Cg9UcnHn437EbYF6JIPa4TBWnxESr7BhgeHFD6TRVDGuuMmP/LyaY8afaQLtwdR/ij/5gnf0e1jEvB5xGETp3WhjuMrKQIAk12p5LghrGOcleuCvD6BrgC0XBbkZnEdoiTS84qnhF/lYtWiWYh1hDZQxoWz2vXa0FJiHmWsN S0k0+GU6 r+ACaTnhZIFCNIf7ye8jpvRsrDRnIEyNvaRxPy5E9S+LIRvtK7CBdwvxQSbi7Ncaev0s0Li7HFewkmHFE06WcESMnhjC5jGx/oBKDxkexloyRaSJy3ICEDYVUTh2TcnOE0Q98h8Kg2sZ+1h22zd5LvcpW8jyoxTgipzqMxo2GrJqMU4oVta+MD4CIVKs8zzF12nlIiOKislQFKR4QiLVLcgxdVi0wcpSRnaKH+BSWd+/ym0OcST/WHTfhntgSPRO6es8EZxbHb/KrjeYLuYVrc3A3NWrE0Wd/44sFmOwv114kfOORIFYVgQWT5g== 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 Wed, Apr 23, 2025 at 8:12=E2=80=AFAM Tejun Heo wrote: > > On Tue, Apr 22, 2025 at 05:19:31PM -0700, Suren Baghdasaryan wrote: > ... > > 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. > > The easiest solution would be switching the modules to use alloc_percpu() > instead of declaring per-cpu variables statically. I couldn't think of a > better way to support static percpu variables in modules and still can't, > but there aren't noticeable downsides to using dynamically allocated perc= pu > variables, so if you have several bytes here and there, sure, declare the= m > statically, but for anything chunky, please use dynamic allocations. In case of allocation tags, we are trying to minimize performance overhead as much as possible and allocating their per-cpu counters at compile time is in line with that goal. I'll check how much overhead dynamic allocation would add but it won't be zero. > > Thanks. > > -- > tejun