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 CFE43C71141 for ; Wed, 11 Jun 2025 20:35:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 290BF6B007B; Wed, 11 Jun 2025 16:35:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 241C16B0088; Wed, 11 Jun 2025 16:35:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1309E6B0089; Wed, 11 Jun 2025 16:35:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E8A5D6B007B for ; Wed, 11 Jun 2025 16:35:31 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 6756581688 for ; Wed, 11 Jun 2025 20:35:31 +0000 (UTC) X-FDA: 83544275262.29.8984B2D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf14.hostedemail.com (Postfix) with ESMTP id A53F1100002 for ; Wed, 11 Jun 2025 20:35:29 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=saWTRc82; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=tj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749674129; a=rsa-sha256; cv=none; b=PG5TT0yDqmrq4+TlI7+ppmQJUrbJytJm85z6g+MOgskTIS5ptpNwFGtBP6vIOrcMolcPMw wWyd15z03diB8JfWDqlXYErGckghUu4+XZMJ1J/wJX6I6ejBtd6QIJAKfsPWQ9VqGjO+Ye mjNxJsAd3iRTXCylYdA84xXd/y1a+Zo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=saWTRc82; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf14.hostedemail.com: domain of tj@kernel.org designates 139.178.84.217 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=1749674129; 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=qISg8jW0WwhkUJiflEalxnrOFpSYXPTUHXBVwrvqRHc=; b=websEINdPsOqTLfuy/c+slItFxl+jSqhAXGIszygDo712d0S6suSUM1Dl7j7owCx8CrB45 xsS7tUyUUxWEqNuxEaGB1IGa9P2dFjJI6B9UJZCIO522mMXQ2tRMUrtVtTsqAjiTXSoOAX t8rgVnslXTnh/3cDeS62t1vMe3g2dUY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id DECC45C4797; Wed, 11 Jun 2025 20:33:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 128E7C4CEEF; Wed, 11 Jun 2025 20:35:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749674128; bh=GhM/Czb4on/qNrxIIcozhACU2W2zoZYLxOQ6tfdHUXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=saWTRc82O3irNS3MpxjVvzyZ4wX7xi0aHOESlwvxMDZlOQSNcIq+lO7aEjZY00Kij p4eGH6tiqllu4GR/yVJiKS7QsivAnXj2V5nyJ+5aE1itNXajk6va6F6dw9ILD1aXZC 6Emg9CNCCEpiSnysaVRHm4SPc9eJKhC5hFu5zTiAEi7NosUfbk5XDfuRnqcBRzi2VD Fsuudjm1zE8cCEmP6gMCoh6bC27pAOSDpm3NA3X89nWaG5dxSSrPNP9P1GFcVy7n5R ArGQM8WfDO0/QyUW4GBACV/onCAGKjUYVTEhrSRkfY3ydhMaVL7ZMAa5vgrkkpbQ21 CvUSqQFTeIfKQ== Date: Wed, 11 Jun 2025 10:35:27 -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> <20250611190642.UHcmUwVg@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250611190642.UHcmUwVg@linutronix.de> X-Rspamd-Server: rspam01 X-Stat-Signature: iz75dskiwumut64st8sj9uh6fdrnot76 X-Rspamd-Queue-Id: A53F1100002 X-Rspam-User: X-HE-Tag: 1749674129-26162 X-HE-Meta: U2FsdGVkX1+JoAIEKnx86SYG26+kq7TGoa6/ANlHhhZqFH7k+u80jCaEJGgQvOXcEJTZt0UKAgRSaEsNJqyiZz7UEZsBWzLbcfJf67aDaY1sEMYWToISPEK+siH4VWtgxkQLY9D8x6pni1SzzDVUpmnIwA1KLmhvlhFwRfQ16NghmyqeDw7bbsDRM6450mCuo0tXaFpt5x+S2c+163/Ffhcu9b0/mf/dY8Z+qkLUnSaOzwIudGJ6BjZDL0vQSKPJ1+ceVG74W6uFFrE9+wZqt1llIPw3eSL73bpasuU+CLriWdjXCpEtUai3I+eHnRdEuS3V/R/nvgitDjR8SV4aYXVfkJLHK5zUhLmGXYOIaSNgseQ6pq+gyJFcFmm6v9FoAbNwwfXY1do5WSt6FT0CcyYAyPJNY3d31l5NH9WyykR8XIyM2r7sh41aik06hqMvhVBnSlZeNWh3k06W14C0XJpp8XdGnpOjMUChecRZaE4kcz9RwseZKNm6z/HNFd3itKI1dnKsf6zrR69LpvFA5E5mCEdArXrZIRy+XvELV8DUxlNJG9etPM4DA4NKWPbaLc0HXq/OpOnrbss3H/9ZtFp/lJzIh+VlgCyvllu/jldXb+qBKJjinIH71kXONpms7Fh57ttgxh7y7b175dTmQ1yWT7dwCeM3hipX/GI3UcAkD21TPD7B0qN+IO16R11GCfyIUzs9hugZWXZhmtbJCcUiv4qaMLHnAi/FZgL3wkWk7g6uUNOvq4KjdSjVyHSLdCKo41SfsxyU3KQrwCV2g29QBDJAQpzLs3P2OOPLc1dXqMtdNSDJsgQ9XfWCFqPRAt/FIuBfkiQhffoQPDkUgDCmVHn2D4wny1STBrKFYtCWtcLVSFBsVWcMQmmULx91R5xqvOxTZVNtTOkkR+P25OFeq/pY5CkPt/5pa9oN+F03JuNFlohqargsITuffiaPR5jCJfP3W6xxkBRzkU1 Dl+6HKyN zDZ9Wj+CF0ua1wat+BOzOecg8G3nvUbhslGz5lMNzakWRhC6iuFTIWwYs3e+BqKWCejOwW0e+Css2erHpsLEwp9zBBHSP8FTWU1hDq9fM5Gbs7Pa78oVWc73RMr5BHDCV1i0Q+TB7yk+yGDvkDw9ZISuiePt6Q+MZJuGccH7nVkfXPaAq/O7QMuvI6+jItflMWw6kPtUFGRYeqWQ/Y+jx0Xz54u5sGJ9Z8FzZDXGrQ73EQyidk0j2uxVP8uCnoYnr3xmucIuffNPqwjyCz46bCB4IRcCQPxaWYPUG 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 09:06:42PM +0200, Sebastian Andrzej Siewior wrote: > On 2025-06-11 08:37:13 [-1000], Tejun Heo wrote: > > 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. > > Not sure I waste two pages waste because the memory is allocated once > used. The reserve percpu pages need to be allocated on every machine and most machines wouldn't be using openvswitch, right? > Anyway, let me redo it to the dynamic allocation then. The memory of the > single module is quite huge. I looked at the per-CPU allocation of all > modules built with a Debian config on x86-64 and (ignoring alignment and > the openvswitch module) it was below 4KiB… Yeah, the percpu module static reserve is intended for things like individual pointers or counters, not big structs. The limitation comes from how the reserve area is implemented. Because of the addressing limitations, it has to be close to the built-in percpu static area and it's beneficial to put the built-in area in address area that's covered by huge pages, so we can't really sparse map them. So, the end result is not the greatest - modules can only use small static percpu memory areas. Maybe it'd be better to outright require all percpu areas to be dynamically allocated for modules but that seems unnecessarily draconian if you need like a couple counters, so this is where we ended up. Thanks. -- tejun