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 A98F8C71136 for ; Wed, 11 Jun 2025 17:45:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DC596B0092; Wed, 11 Jun 2025 13:45:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08E496B009B; Wed, 11 Jun 2025 13:45:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F0D366B009D; Wed, 11 Jun 2025 13:45:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D17346B0092 for ; Wed, 11 Jun 2025 13:45:50 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7A7861D6D0E for ; Wed, 11 Jun 2025 17:45:50 +0000 (UTC) X-FDA: 83543847660.01.A2B56AF Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id DDB3CC000F for ; Wed, 11 Jun 2025 17:45:48 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s+2LwHgn; spf=pass (imf22.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749663948; 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=IayfYIqhWsSGmjtvYBim8WfLDZeRFht5z3wQWAlSwk4=; b=vSYH5w36QCr/lqhK3IDB6VTP0UbbLURWZT3bQNPNQi3gk6aByil1yjfnBWshswZwwCP7oh o2IaQn8w5VS4xAWQwz7H5ZMeHNiiVC34FQv6Oc70DFg2VumHyQjagfJZGJfFhlJtZQ5xqY mSjyBbpxrENzpJnRwuR/SqhQ35gu7n0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749663948; a=rsa-sha256; cv=none; b=NQgtXeX08oWEXoBsXKPuodhlmUbwvGLqyjo4Mr1WgJ5DsD0T7QPiQMgeHVMTHgevlsBTVC IrdI720uUeXrinOXED4Lmug9ojadL/VBmEQnY/YHD21IfwV6FzdmxPWmIR1OpJuQJ+Z0O1 BHxqp+efVoCdBuPMLH58pDe3X8nGnP8= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=s+2LwHgn; spf=pass (imf22.hostedemail.com: domain of tj@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=tj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0A85D6154F; Wed, 11 Jun 2025 17:45:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89664C4CEE3; Wed, 11 Jun 2025 17:45:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749663947; bh=xP4YlUpMvbwtp4vhLWVvnAsxa5crfEHUGzEpbuSxdEI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=s+2LwHgn7C17OQwh02ihfz0sJikijHRVzaWHsQox0EtGZYHnhlbicQZVJtCBtzyYC wWRX2q6xOOh9pKJ2uHzrOgSKnktwcwnd0hbXv98dIEBOslrcDWG06Glugi6io9WGNv 2aL1sFO668RElRB4Y32e5uukcTd08zX++2lDiCA+SDsvIvYRSBDdZ/qLQ8sDniAOsl gkWOkjndErUMpo/kZMRLMNDERNVHt6BS9zy0zeR7gdk5KjaM20foYhlpJYJ5YUqLTM A9kC4ZRuoHuLUm22Bvz8JPPs8RAONSoRMSEwEhQrP00s7C44XrJzOyRFMfei+Y8y7K lSnlyKFLgJs2Q== Date: Wed, 11 Jun 2025 07:45:46 -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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250611161849.BfhxVtnk@linutronix.de> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: DDB3CC000F X-Stat-Signature: p15wbnecry7fpcd7ixpcjk95i7unfpht X-HE-Tag: 1749663948-972294 X-HE-Meta: U2FsdGVkX1+URRUbolLMl467yU2SPbo+rpgDsG5lcu7e3xu8ql1+607bTYrRuNo8YPgI2KVjij0CnD7jyBaZG+iX8qbDsJc/GMOiDlWCiluHJ0ZaTDvw7iU6ZogkmSzz3DAjlJjqAclO+eKur95nDMoXCA9lHnJmR1+Uky4B255UbteYPlC1VhXINQdRdH+phU0BH2d30cucQO2fy5MHMWEUiP+eYT8VQOKIySc3qhi5VeXxDkZLdTP7ezI4cZ5xrQTvoyqGB86GNBz7hQcLNrZjTA3dl5w4+t29lLYNKBy1miUKZEY+cMMU9iKQ4WsLUL9V5vdJKlbFG2b8+nuoJBXOp5/DCD8xU6OOkDTrg4wBGCsVW/xg1sY+ag7+PNocGIiox4gyu0/t2tNV9IWpu4DFGfwceKC4zspjBVKKY1PwNz6Eyo77fTAb0OG8B9MErupsrYKEomj2NI7YhvanWNcS7lfeT6s2YhX6pQeEBfn58rxbMQ+YD2790adrtCYiMwpEImD3mO6RsBH/+FkOULuzC+gC5fxiiXIRtUhqKpr9oazrTG+ZEpu6ZmIFj1ctWDbQ9H1emOyBTutVrb6V7+an/BEOJiSedQuRUHGRV823wsP6D4TFIPfjWjGCm+2JLePeFdzj5BXRJoWOaeO8MxpqUqtCFfIo3AQH6DqqFgV1UzHZ1PYJBOYHmn64d0vNE9z9goC0zysUrSywIf/O2xZJFLjXsNhFhXdGxnY1Ct/ev04NWhIRFwWOK2/pMsYisVgoNYjtUQT5vXUJQ6DVJ4d7TrrT9zLGLkVpKRlKYcm+mXZhiXWw09sssf/LxIxS/VXHctg/+YYO2ZTAb1icTppy2g30saUUoAkaYaIIr34XoxLSVDv0uJjDVdLifAV/Xi7NaxKeNj3ier+5QE80KBiUrGY/p+4Jf+SMwUFwPxXxQJprncUEomVAEl3Plb//sjVsUnlPaMbNsdVOsCR RGSVYmTT /kL3D55XdAaGqmmgo7gJgwEhLWqFAfQWSbcuE48rJzEFgB4gdhX4DZjGDlYbvfW0xdwU26i1q2va4miODdK4jLGokMRfHWWK+U+FD8H9x/e0gkX5AENYYCQ97Jm7S8G5oofQcK1ompffkh3R6bXQTpWP2+Yap6piohhL5k8Ai5YgPru4NL+oO0Tz9qGSQiUOwDvmSvjPQE8tThCfTTLnC+zW0Y+k6YviKSBA5wqJZi+7M19WBvSWjXrLkwg/RzIA1sfJp 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 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. Thanks. -- tejun