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 96476C83F25 for ; Tue, 22 Jul 2025 09:42:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C35B6B00A3; Tue, 22 Jul 2025 05:42:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14D756B00A4; Tue, 22 Jul 2025 05:42:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03BBD6B00A5; Tue, 22 Jul 2025 05:42:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E054E6B00A3 for ; Tue, 22 Jul 2025 05:42:32 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 646D41A02EA for ; Tue, 22 Jul 2025 09:42:32 +0000 (UTC) X-FDA: 83691410544.19.CF6B075 Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) by imf11.hostedemail.com (Postfix) with ESMTP id 9439A40003 for ; Tue, 22 Jul 2025 09:42:30 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b="FeLF/FsA"; spf=pass (imf11.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1753177351; a=rsa-sha256; cv=none; b=0Um+mKMuxXBmXH2hJcGcIzsLG/P2AuSzQ7yk0KdVj5k4ffjdITEpXfZqDsZ1dkbN5ephAQ vwgx0Mf9AFAMGGgqJC3qwhXi1h4EsM6qc8mLZmu2BOyInZCcSz0nNiW3WnMxRElVJuyj0Q X/zgx8cmyWWzIvuD3zRYLbXO0Zioui4= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b="FeLF/FsA"; spf=pass (imf11.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.161 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=1753177351; 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: references:dkim-signature; bh=Urh8HRRY5Gk+UX/47pqglCk6rC9DKpiGj+KUTBX7+cY=; b=1OK1N+TnszlaeWmoiUjlE6xXFMqz7lgCwMTW6Zx4GpBCzp11MGnAZgXW28/bPMFbxkqr+1 mu4LeZHo4SUPIn8iTlexoSqw+y/Xy3II20PtSlDHvkkHmHCWY+PORbMdoAupqIsCmV1uLf urhwAa7njKI4BnTsnqyShyJg9ama1X0= Received: from smtp1.mailbox.org (smtp1.mailbox.org [10.196.197.1]) (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-103.mailbox.org (Postfix) with ESMTPS id 4bmXNx6blwz9svV; Tue, 22 Jul 2025 11:42:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1753177346; 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: content-transfer-encoding:content-transfer-encoding; bh=Urh8HRRY5Gk+UX/47pqglCk6rC9DKpiGj+KUTBX7+cY=; b=FeLF/FsA3wnqiSqMvPDYZwXjDYrax7X5skBfXJfI2kZXS7eGNxN50IorUfg0OnPD8REeJr LlX25h8JS22JeTq2p1zSBtLPDoufAANC7db1oLf2E547fIr+pD/dv/sNpk+CW6NQf0MMep hWP9OyYnFugTJKRMkt/yEN7Ob8j2Enk4C6fnWfMBFEBwQm8IduHD7fzxaKLoWi2iPOF6z2 lz4w8/FflPazzxv3QZfINLJ4nOxXv4qfS6Ty74WbcbWUpcHC3zEPnzIUYagnD8R8tnDDIp odpa1i++gPK91rL1aDstJtoL+LwOPBrs8Zh1aFZ6Ba84rXirsSBm00q5k76Sbg== From: "Pankaj Raghav (Samsung)" To: 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 , David Hildenbrand , Lorenzo Stoakes , Andrew Morton , "Liam R . Howlett" , Jens Axboe Cc: 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, kernel@pankajraghav.com, hch@lst.de, Pankaj Raghav Subject: [RFC 0/4] add static huge zero folio support Date: Tue, 22 Jul 2025 11:42:11 +0200 Message-ID: <20250722094215.448132-1-kernel@pankajraghav.com> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 9439A40003 X-Stat-Signature: gcih9ywa3d3z3oznhtk9ag6eac4itn6j X-HE-Tag: 1753177350-471263 X-HE-Meta: U2FsdGVkX18wnHsgBb36c0YmofiGxmOFeJfVWKHy14rA7d9+N2UbFE07g20ie1gR5W0L1cjd1vU2RYSGONV988zigm6vOJfZUMSwDgsIG5NBNzy6shoZVmP6CRYUcd6HS+bUHqBLPPB3BLWcjbwqwgelkbRvPDvsl9L5tslCU14DZbzvKaN9/T6o7HWzazhheBBVPfFRUBzuG7PvWadcXCyQxzElalCI407DHntqPI6vx+eotpZHA1DSE8IODqI2feqWfsckeXWRI5CMOmN5w6csj8v4MSlJIPENKx1TRD9YbnVwq6DVYdJPCR+NoysItQiIcsZYPjTGj4tMdAuwAeRubPNryEJ5bBH0Xb6IJ82Q5ALKqKraBTd070I4ObQF2cXPe5mgLI716slbMOjikGxCPglKAd5ZTqBFz/3I4A/iP9knrBRoZtUGvi2ZAVGFPcpNPp/LNElrPCAOXIhtoHHfwfCj8t0uLgJnm888waJF7iSN1cXfyHPsBi4zZxiyVlj9bjn8dC9+Xv9CTot9PuvaxAX/I6QwQZwYuiXvgeFrc/bv/CnsbJMZ5KrWCPxaAVRc1YXM+/pL/saomcmBwIVQxw4kav0dTg8GdIFKqxx0IKAgYRIKE/tB2yJ8qIBTG9BtcBPfLbt2ZArHTrK7YjsDOYQB3JCkPNmchgW5Aabx3e+IwfR2MEOZuLnvTGd5z8EEQ8k11yenH6puaKl+675CuL4SdgvH5p9kWGEL0maD8XhktS2XQ12JiZLpYId7P2LjzQJJ7a9U7F12WWUdZ31vO1+cjPWzbqoSZMY03NEmDnmodMrwgwSoTpoXEFPXYi68IFgfeUg5P4T8qNSOyCzkwIJMO64Mjvz1R08RPEvvMMJJTx9W433zGK3lGtA1OmE+vFlIiUNTAtUXmPgaFu36lQptaQ2r 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: From: Pankaj Raghav NOTE: I am resending as an RFC again based on Lorenzo's feedback. The old series can be found here [1]. There are many places in the kernel where we need to zeroout larger chunks but the maximum segment we can zeroout at a time by ZERO_PAGE is limited by PAGE_SIZE. This concern was raised during the review of adding Large Block Size support to XFS[2][3]. This is especially annoying in block devices and filesystems where we attach multiple ZERO_PAGEs to the bio in different bvecs. With multipage bvec support in block layer, it is much more efficient to send out larger zero pages as a part of a single bvec. Some examples of places in the kernel where this could be useful: - blkdev_issue_zero_pages() - iomap_dio_zero() - vmalloc.c:zero_iter() - rxperf_process_call() - fscrypt_zeroout_range_inline_crypt() - bch2_checksum_update() ... Usually huge_zero_folio is allocated on demand, and it will be deallocated by the shrinker if there are no users of it left. At the moment, huge_zero_folio infrastructure refcount is tied to the process lifetime that created it. This might not work for bio layer as the completions can be async and the process that created the huge_zero_folio might no longer be alive. And, one of the main point that came during discussion is to have something bigger than zero page as a drop-in replacement. Add a config option STATIC_HUGE_ZERO_FOLIO that will always allocate the huge_zero_folio, and it will never drop the reference. This makes using the huge_zero_folio without having to pass any mm struct and does not tie the lifetime of the zero folio to anything, making it a drop-in replacement for ZERO_PAGE. I have converted blkdev_issue_zero_pages() as an example as a part of this series. I also noticed close to 4% performance improvement just by replacing ZERO_PAGE with static huge_zero_folio. I will send patches to individual subsystems using the huge_zero_folio once this gets upstreamed. Looking forward to some feedback. [1] https://lore.kernel.org/linux-mm/20250707142319.319642-1-kernel@pankajraghav.com/ [2] https://lore.kernel.org/linux-xfs/20231027051847.GA7885@lst.de/ [3] https://lore.kernel.org/linux-xfs/ZitIK5OnR7ZNY0IG@infradead.org/ Changes since last series[1]: - Instead of allocating a new page through memblock, use the same infrastructure as huge_zero_folio but raise the reference and never drop it. (David) - And some minor cleanups based on Lorenzo's feedback. Pankaj Raghav (4): mm: rename huge_zero_page_shrinker to huge_zero_folio_shrinker mm: add static huge zero folio mm: add largest_zero_folio() routine block: use largest_zero_folio in __blkdev_issue_zero_pages() arch/x86/Kconfig | 1 + block/blk-lib.c | 15 ++++++------ include/linux/huge_mm.h | 24 +++++++++++++++++++ mm/Kconfig | 12 ++++++++++ mm/huge_memory.c | 52 +++++++++++++++++++++++++++++++---------- 5 files changed, 85 insertions(+), 19 deletions(-) base-commit: 1b0686bd18c1aa9d7f01943829faa5befe6ab3d1 -- 2.49.0