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 64187C71136 for ; Wed, 11 Jun 2025 18:37:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4E506B009B; Wed, 11 Jun 2025 14:37:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B262C6B009C; Wed, 11 Jun 2025 14:37:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A63F46B009D; Wed, 11 Jun 2025 14:37:17 -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 8602B6B009B for ; Wed, 11 Jun 2025 14:37:17 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 39CEC1A0369 for ; Wed, 11 Jun 2025 18:37:17 +0000 (UTC) X-FDA: 83543977314.24.CE07D12 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf07.hostedemail.com (Postfix) with ESMTP id 89E0440006 for ; Wed, 11 Jun 2025 18:37:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fojoxYeW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749667035; a=rsa-sha256; cv=none; b=m7NHvhhBi7JcSZflGiWr3tvNaidffH7qVyPJasCVHXz1m8LE86yYbBgzYthDwioUBUk5WY L/B75mmrXD0WgCwiSAvlaxwJkbadToTaWd6Npj0AKQZTOttrev0Ny70c0DCQTvaI97FQ3Z 2uhh+aU7goKiqaC0f5foMNSijv2qipw= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fojoxYeW; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749667035; 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=6exOEHKl/6VFMUMFjYZU5QiCyN4UvlzrMmo6Z4GedAE=; b=s3zfhBp/lONQYIHYpxXJdO+n1ehk2lxUlIVmbFuNwaCZA2hGY6Snp86d57zq0jMttuZ79Z 0QjdJldzfgP4W9CwtpfAIBcFLQo6YeTHju5tjVQcbzFcs4ffhiqNPBlB0lbUTEi/ePrAjv lfXz6aavdftgdxS7ZYNfrOmc04g3nT8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id BC45261F1D; Wed, 11 Jun 2025 18:37:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47085C4CEE3; Wed, 11 Jun 2025 18:37:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749667034; bh=/FNet4VsQ05KJMy9jczKa+8H1vn+Eg5t1RZBLsSuR3g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fojoxYeW6+vnZBlir+FpWYaIZnfAbH2i1RWgNXZfDRt/5+wSuPfRP1DXFbDTtDGQN bnatP5HTb/CdKH729vY5iktunJ7+LZTeUxXJIfFshc/SF3R7nHwkLjwYX2Dewex5Hh ggDaDW+Z7x4OhT79eYDKNAWLEH1UcKQO+r8U4ARKkTnAtnTk4F0shiYyY1hDSghRhj cbHjFTPAaFVUCjxfwcozn8ucsiTOX1FYDBb9x9N/+sqOns+/8nv0gnNXt517MiAzUr 4vAs4RozjVYh8Q0mclRAEb5H2wTLLCxc7VhfFCqm/gHFzHXhkYOwvZarrCSU5HxKgL QRDFL4CVlhu8A== Date: Wed, 11 Jun 2025 08:37:13 -1000 From: Tejun Heo To: Sebastian Andrzej Siewior Cc: linux-mm@kvack.org, Dennis Zhou , Christoph Lameter , Gal Pressman , Peter Zijlstra , Thomas Gleixner Subject: Re: [PATCH] mm: percpu: Increase PERCPU_MODULE_RESERVE Message-ID: References: <20250611161849.BfhxVtnk@linutronix.de> <20250611183257.luuJewNy@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250611183257.luuJewNy@linutronix.de> X-Rspamd-Server: rspam01 X-Stat-Signature: 5kiuy7oty3tohfcb4k474jaake4kbait X-Rspamd-Queue-Id: 89E0440006 X-Rspam-User: X-HE-Tag: 1749667035-229261 X-HE-Meta: U2FsdGVkX18B22tYICZ3FTE1pT6uKV6/Q8fJUI4bEjADmuu5PwtliuetQdI2ocM2M+FWUMRnhI5lnk+oLNEaoD3YRF3fYZ1F5E2wpx5sDFmi3G6XKu/4sHb52EG61WASULwC8Gxv0LYgA3iQbmv7h9Im2uNzJEoEuAtzyxdmGZKMdueGSWrTY95HBRpUEoJID1LuYOyIBZsdkIlxAQzyyuvc7yyLyHZJVyklzvDX2ub5H/ay7BhXArrY89txSWAUMKW7+o9xaxWzd7iCfw8nxdIHAZ7Ml2SuEs5JLQB0xLnglVxZw5b+rSjfCTzEuVXoK4GlkjFcd5IMQI8wZSlhG6m2vToWqPUYGkGqtnjDMnVQ3k4c5ayI1PQavoISAuAGaFdmWdpG6FoOmOkqsRnCGTGWv0Mg7vCuDvR4ykq8HOub9TiBAWDqGYew0VAwgFD9kC7KO08gMYvVUB/WJRuA+HmaWDqXWlsYPWtW4/bNq9A+gRwsNebv/ssZNvV9RuDFbiYrWKHYwa/pF6DWZuDZVZQA8wvOOTMGTYKOxNp5ec4uDFIiichwo2C+ZLxv7MPcaojkSSJ5kSGYg35fEeiW2FNrwH2yZEji24TqFAdCynoShZsrbvSCQK5zE9q15+JNU74yeJ+As/LjNBZUBD4adoBU13U+87YXxC/FI429j887pjS6BqwJhcNx6hSTkiwpmtoGesDtAP2XfZa39OqPCQl4GcIDfud9YHI1EofRdSU1+a0Ad9X4687kGhxaQd/6WCqnrfc/NSbZezpwtLI9vUrNjPSgU7Xbzq9sped2Yss3GJMzPn16X3CygPvBaXFnfLpoqvYGdRknvGtlmW7bGgUJFMYMv2JWB6m3IccecRcHbHg/cx/0R8FbLDlF4ve49nhVxbN7nl/FWALB3P/JtL2Iqyqgr6fRYnv5ocAtxzIND1OkcYum/V64X/TYWN/qiCZ4Jg4aYsU7u5uaWJu BXuJjKaX xhm3cFr/C44FDYhNJg9E+qXcUl46DerTRSAj1MhO3vHgNWy5aUNlqJX+MneK2OFpL1b6XzeqvCFAQ8LRJSN1qOFcTMw05caZ+A3eQt4P/U7cyZnP2cgo1U4UQL7q50jtlbT1+4iJmmL1XfWJkzGFFL89UdrGa8jUjCJkbX708CKBUxc7GA9sA7gXwB7Q4xR22G4FWpkoLC008Lxg3Opst63BMVRMocExVzzw16ybkM0/DhgUjROLx+M4Tu+n0iAbicf+H 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, Jun 11, 2025 at 08:32:57PM +0200, Sebastian Andrzej Siewior wrote: > On 2025-06-11 07:45:46 [-1000], Tejun Heo wrote: > > On Wed, Jun 11, 2025 at 06:18:49PM +0200, Sebastian Andrzej Siewior wrote: > > > PERCPU_MODULE_RESERVE defines the maximum size that can by used for the > > > per-CPU data size used by modules. This is 8KiB. > > > > > > Commit 035fcdc4d240c ("openvswitch: Merge three per-CPU structures into > > > one") restructured the per-CPU memory allocation for openvswitch and > > > moved the separate alloc_percpu() invocations at module init time to a > > > static per-CPU variable which is allocated by the module loader. > > > > > > The size of the per-CPU data section for openvswitch is 6488 bytes which > > > is ~80% of the available per-CPU memory. Together with a few other > > > modules it is easy to exhaust the available 8KiB of memory. > > > > > > The memory range for the per-CPU memory is allocated early and pages for > > > its backing are only allocated once the per-CPU memory is allocated. > > > Increasing the map from 8 to 16 KiB adds 256 bytes to the alloc_map and > > > bound_map and 64 bytes to md_blocks (576 bytes in total). > > > > > > Increase the available memory for module's per-CPU data section to > > > 16KiB. > > > > I think a better direction would be keeping using alloc_percpu(). There > > aren't a lot of benefits to using static definitions compared to dynamic > > ones and making it larger increases overhead for everyone. > > I could avoid initialising per-CPU locks because of the static build > time init and avoid the alloc_percpu() at module init. I can access > members of the struct avoid one pointer dereference. All this for 576 > bytes. Yeah but for that, you're making all machines that run the kernel to waste two more pages per CPU. Modern machines are big and the overhead quickly gets into megs. Sure, it's not a huge amount of memory but it's going to be memory that almost nobody uses, relatively speaking, which just sits there and gets wasted. Thanks. -- tejun