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 75B4BC71135 for ; Mon, 16 Jun 2025 10:49:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13FD66B0088; Mon, 16 Jun 2025 06:49:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CA006B0089; Mon, 16 Jun 2025 06:49:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id ED2FF6B008A; Mon, 16 Jun 2025 06:49:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DA9D86B0088 for ; Mon, 16 Jun 2025 06:49:40 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 6EF82101B35 for ; Mon, 16 Jun 2025 10:49:40 +0000 (UTC) X-FDA: 83560942920.21.8D9E7E6 Received: from mout-p-101.mailbox.org (mout-p-101.mailbox.org [80.241.56.151]) by imf11.hostedemail.com (Postfix) with ESMTP id 8F7364000B for ; Mon, 16 Jun 2025 10:49:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=JbX1CR8R; spf=pass (imf11.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750070978; 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=XY8QmFX6C/sGkVxyzcatdwuMOackSJD85Ys2cJrlHdU=; b=Klf1Ug5lFzxUk2AfKyknuOmNDE3B4FPNf3oyZU1SrUtPtjA/KnTvdq0xica7Od4rKR2OpM NvkIUF9ICiMOljZ4p1v4UPPevrT9XeRbkvL+YK8jwIrRwB38YLbBcHlsXka/wQ7kmauYai 6m24qTNmdif3k0tuODmOK1J0t0w8pbQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750070978; a=rsa-sha256; cv=none; b=tT8wXveJPFkaN7Cb1FxCjIIJLs7uxDXZHPJ6DJLjphlhKA82stovjAk0QpVfwwn8zvzfKx sN2mWX/UerJiqMPuUfx7DS9lW3UlA8wSjO3M/fAIoBDTjJJpMk2vSINadWPaCv3MNgYBjl TIFIXKezRbM+bviJs+4KN7YCkR1nepE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=JbX1CR8R; spf=pass (imf11.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.151 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com Received: from smtp202.mailbox.org (smtp202.mailbox.org [10.196.197.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4bLRb2549Vz9sQV; Mon, 16 Jun 2025 12:49:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1750070974; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XY8QmFX6C/sGkVxyzcatdwuMOackSJD85Ys2cJrlHdU=; b=JbX1CR8RBtgCBQt8jaWY9VXnIednZIJjOtAvoib1pnvZYtCrjr7WedGKILsmrbjHc5Ejk1 U+EYALUUEEX7ioXOI0+f8htJlHxdiyPInM69QH9+x/zQ9MGxC/PYi1zKomi2BzPQ+ryMgM LWBw4qAe5jDrzf2wJNd56YTxKrpD5t+Nr9QYUhJnBmX3C3Qd8H3J9THwBFFDwS5ccAnMAY b6qdhL6RV5rmJCmXJv+c3mSrO2OVMeCWO6CN+ZTHSWd9Ne1KohY8T48fiOHT6/Jy5pikcV D12PQCDwZVtg6fZKx7tvUb43RvI0lMB8MnmpErrcoKnSAoVyj+TX4ORp6a1K/g== Date: Mon, 16 Jun 2025 12:49:27 +0200 From: "Pankaj Raghav (Samsung)" To: David Hildenbrand Cc: Dave Hansen , Pankaj Raghav , Suren Baghdasaryan , Ryan Roberts , Mike Rapoport , Michal Hocko , Thomas Gleixner , Nico Pache , Dev Jain , Baolin Wang , Borislav Petkov , Ingo Molnar , "H . Peter Anvin" , Vlastimil Babka , Zi Yan , Dave Hansen , Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Jens Axboe , linux-kernel@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, x86@kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, "Darrick J . Wong" , mcgrof@kernel.org, gost.dev@samsung.com, hch@lst.de Subject: Re: [PATCH 0/5] add STATIC_PMD_ZERO_PAGE config option Message-ID: References: <20250612105100.59144-1-p.raghav@samsung.com> <30a3048f-efbe-4999-a051-d48056bafe0b@intel.com> <76a48d80-7eb0-4196-972d-ecdcbd4ae709@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 8F7364000B X-Stat-Signature: cyb7aq6a6afm1sf8gcr3uz4s4h9yrdn8 X-HE-Tag: 1750070978-47650 X-HE-Meta: U2FsdGVkX1+hBcbxe3ACf28MxYNRQ55xo36EhxUBsZFn5HO/XbH91A2uqRkpwqIjSEXmI8R1NbApmGPOVZAkc5ABMT7yqTCAzSN7E6aPSHZ9yeaASVVv3nsQGF3LDjiA33gRvAo948PZRgbZ1JunpNY3P8cyrbOa8gLgbKteXp6ylMWUc/CQjlMeCsLeYpaYttOL4ZbPQpNdmHmL2p4PKuzRIcUQQmA00NyyiTNbdyqTfdNuw1fvz67IhxfaiKUJ8jVGOcGnPoYkPP5mo+eRRdXuvCjOxqWxG2mO+YlNSGBLw4vUQlYDoSWd5pD9cvTU9bHBmbavkPBB8hlMimou2/b+FtxS6OXh4PjC/q6jn2Z+HWgQtbN29fh84ZSaK4adA+6azCRSsPp7BEtHhX+0N3EXU8+PMWJahj7Ni3e/cAk/WLNIbfr4jEB5lGFtxfepiirjV9pMzneGzihP3lU+oEaq1BCHQCb9IAHE3nyNGi4y6IUIFdsk3I0p0uE40Lpmox/vaR9p4HdzTzPELLG8ZExUFT4PEy00A88KilH9/Y5nAr9w2E6kO8Q4SX9pdWUByOikXibStSp27I23cnXEB3R044thdFDLpgy592izCkextsNnM+iYUxn/dtahBQsjKpPXrEgnfwgacaFLWNx2m68g6ifOJy0lTECfBdIscEVUpHckmqJrWAnGfp4BneQQ1IG2yvX4hYFihi36+kDFGK6smiQZ43gvFy9gl2mMb3a7FHphu+mR9NBbrEOqDl0skkhYP144v3FYA6SXUoj1CwWwSP7AqXyL+IE8tkO/z6rtmguUawnPLwfyQDN+9FR+PQNYPcH0+mZ386pC6qjjFS0y+Aa2bHLT6EaBrM3iNonstrvH57aBL5yGBOolWexePO5waO6Og5imYa7zGKFC+jhvpBQZfnz9CZv1aS26Gt+NRg7x9M8pyMhlZK2BTmQHQE2a2nW04UJTgtyzu3Z 2cOP9ZYh qv6KqO3vuIcB3Riy+XGVDzO9AL6u1zpHb0TO/yQdMKnnM1UJzXOt0blL7/8urwt9Ls4zCVqO2tjwS2c0ItNVcpiXnyCo05XmbJgpOoKjbnSulqqJQgr8t9Jz7RqrnfP3v7Q49+WckbIh1a6v5Tg2H95rkS8OPEDScvLK2JOhv5hmtjV8cOBKubk519iMQfw0PUOL1SdePzWFz2PZ8/wMbgoHnRdT6LkVUTMK0fxYcKPFsw8N//ZUMky2CzX13zrGoWTIm23d4/ahAchm3v0f0u2CAZJZHa8An9kmAZZuk4o9tEhZr4RI3wLjJiH8vF7RrOkGMQXxgOpaHW2Q= 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: > > > > > > The mm is a nice convenient place to stick an mm but there are other > > > ways to keep an efficient refcount around. For instance, you could just > > > bump a per-cpu refcount and then have the shrinker sum up all the > > > refcounts to see if there are any outstanding on the system as a whole. > > > > > > I understand that the current refcounts are tied to an mm, but you could > > > either replace the mm-specific ones or add something in parallel for > > > when there's no mm. > > > > But the whole idea of allocating a static PMD page for sane > > architectures like x86 started with the intent of avoiding the refcounts and > > shrinker. > > > > This was the initial feedback I got[2]: > > > > I mean, the whole thing about dynamically allocating/freeing it was for > > memory-constrained systems. For large systems, we just don't care. > > For non-mm usage we can just use the folio refcount. The per-mm refcounts > are all combined into a single folio refcount. The way the global variable > is managed based on per-mm refcounts is the weird thing. > > In some corner cases we might end up having multiple instances of huge zero > folios right now. Just imagine: > > 1) Allocate huge zero folio during read fault > 2) vmsplice() it > 3) Unmap the huge zero folio > 4) Shrinker runs and frees it > 5) Repeat with 1) > > As long as the folio is vmspliced(), it will not get actually freed ... > > I would hope that we could remove the shrinker completely, and simply never > free the huge zero folio once allocated. Or at least, only free it once it > is actually no longer used. > Thanks for the explanation, David. But I am still a bit confused on how to proceed with these patches. So IIUC, our eventual goal is to get rid of the shrinker. But do we still want to add a static PMD page in the .bss or do we take an alternate approach here? -- Pankaj