From: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>
To: Suren Baghdasaryan <surenb@google.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>,
Mike Rapoport <rppt@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Michal Hocko <mhocko@suse.com>,
David Hildenbrand <david@redhat.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Nico Pache <npache@redhat.com>, Dev Jain <dev.jain@arm.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Jens Axboe <axboe@kernel.dk>
Cc: linux-kernel@vger.kernel.org, willy@infradead.org,
linux-mm@kvack.org, x86@kernel.org, linux-block@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
"Darrick J . Wong" <djwong@kernel.org>,
mcgrof@kernel.org, gost.dev@samsung.com, kernel@pankajraghav.com,
hch@lst.de, Pankaj Raghav <p.raghav@samsung.com>
Subject: [PATCH v2 0/5] add static PMD zero page support
Date: Mon, 7 Jul 2025 16:23:14 +0200 [thread overview]
Message-ID: <20250707142319.319642-1-kernel@pankajraghav.com> (raw)
From: Pankaj Raghav <p.raghav@samsung.com>
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[1][2].
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()
...
We already have huge_zero_folio that is allocated on demand, and it will be
deallocated by the shrinker if there are no users of it left.
At 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.
Add a config option STATIC_PMD_ZERO_PAGE that will always allocate
the huge_zero_folio via memblock, and it will never be freed.
I have converted blkdev_issue_zero_pages() as an example as a part of
this series.
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-xfs/20231027051847.GA7885@lst.de/
[2] https://lore.kernel.org/linux-xfs/ZitIK5OnR7ZNY0IG@infradead.org/
Changes since v1:
- Move from .bss to allocating it through memblock(David)
Changes since RFC:
- Added the config option based on the feedback from David.
- Encode more info in the header to avoid dead code (Dave hansen
feedback)
- The static part of huge_zero_folio in memory.c and the dynamic part
stays in huge_memory.c
- Split the patches to make it easy for review.
Pankaj Raghav (5):
mm: move huge_zero_page declaration from huge_mm.h to mm.h
huge_memory: add huge_zero_page_shrinker_(init|exit) function
mm: add static PMD zero page
mm: add largest_zero_folio() routine
block: use largest_zero_folio in __blkdev_issue_zero_pages()
block/blk-lib.c | 17 +++++----
include/linux/huge_mm.h | 31 ----------------
include/linux/mm.h | 81 +++++++++++++++++++++++++++++++++++++++++
mm/Kconfig | 9 +++++
mm/huge_memory.c | 62 +++++++++++++++++++++++--------
mm/memory.c | 25 +++++++++++++
mm/mm_init.c | 1 +
7 files changed, 173 insertions(+), 53 deletions(-)
base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a
--
2.49.0
next reply other threads:[~2025-07-07 14:23 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-07 14:23 Pankaj Raghav (Samsung) [this message]
2025-07-07 14:23 ` [PATCH v2 1/5] mm: move huge_zero_page declaration from huge_mm.h to mm.h Pankaj Raghav (Samsung)
2025-07-15 14:08 ` Lorenzo Stoakes
2025-07-16 7:47 ` Pankaj Raghav (Samsung)
2025-07-16 15:24 ` David Hildenbrand
2025-07-07 14:23 ` [PATCH v2 2/5] huge_memory: add huge_zero_page_shrinker_(init|exit) function Pankaj Raghav (Samsung)
2025-07-15 14:18 ` David Hildenbrand
2025-07-16 8:01 ` Pankaj Raghav (Samsung)
2025-07-15 14:29 ` Lorenzo Stoakes
2025-07-16 8:08 ` Pankaj Raghav (Samsung)
2025-07-07 14:23 ` [PATCH v2 3/5] mm: add static PMD zero page Pankaj Raghav (Samsung)
2025-07-15 14:21 ` David Hildenbrand
2025-07-15 14:53 ` David Hildenbrand
2025-07-17 10:34 ` Pankaj Raghav (Samsung)
2025-07-17 11:46 ` David Hildenbrand
2025-07-17 12:07 ` Pankaj Raghav (Samsung)
2025-07-15 15:26 ` Lorenzo Stoakes
2025-07-07 14:23 ` [PATCH v2 4/5] mm: add largest_zero_folio() routine Pankaj Raghav (Samsung)
2025-07-15 14:16 ` David Hildenbrand
2025-07-15 14:46 ` David Hildenbrand
2025-07-15 16:13 ` Lorenzo Stoakes
2025-07-07 14:23 ` [PATCH v2 5/5] block: use largest_zero_folio in __blkdev_issue_zero_pages() Pankaj Raghav (Samsung)
2025-07-15 16:19 ` Lorenzo Stoakes
2025-07-16 13:24 ` Pankaj Raghav (Samsung)
2025-07-07 18:06 ` [PATCH v2 0/5] add static PMD zero page support Zi Yan
2025-07-09 8:03 ` Pankaj Raghav
2025-07-09 15:55 ` Zi Yan
2025-07-15 14:02 ` Lorenzo Stoakes
2025-07-15 14:06 ` David Hildenbrand
2025-07-15 14:12 ` Lorenzo Stoakes
2025-07-15 14:16 ` David Hildenbrand
2025-07-15 15:25 ` Pankaj Raghav (Samsung)
2025-07-15 15:27 ` David Hildenbrand
2025-07-07 22:38 ` Andrew Morton
2025-07-09 9:59 ` Pankaj Raghav
2025-07-15 14:15 ` David Hildenbrand
2025-07-15 13:53 ` Pankaj Raghav
2025-07-15 14:04 ` Lorenzo Stoakes
2025-07-15 15:34 ` Lorenzo Stoakes
2025-07-17 10:43 ` Pankaj Raghav (Samsung)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250707142319.319642-1-kernel@pankajraghav.com \
--to=kernel@pankajraghav.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=baolin.wang@linux.alibaba.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dev.jain@arm.com \
--cc=djwong@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mcgrof@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=npache@redhat.com \
--cc=p.raghav@samsung.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).