Message-ID: <e6648680-da88-4f01-9811-00229da858e6@redhat.com>
Date: Wed, 23 Jul 2025 10:45:57 +0200
From: David Hildenbrand <david@...hat.com>
To: "Pankaj Raghav (Samsung)" <kernel@...kajraghav.com>,
 Suren Baghdasaryan <surenb@...gle.com>, Ryan Roberts <ryan.roberts@....com>,
 Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>,
 Thomas Gleixner <tglx@...utronix.de>, Nico Pache <npache@...hat.com>,
 Dev Jain <dev.jain@....com>, Baolin Wang <baolin.wang@...ux.alibaba.com>,
 Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
 "H . Peter Anvin" <hpa@...or.com>, Vlastimil Babka <vbabka@...e.cz>,
 Zi Yan <ziy@...dia.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 "Liam R . Howlett" <Liam.Howlett@...cle.com>, Jens Axboe <axboe@...nel.dk>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, willy@...radead.org,
 x86@...nel.org, linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 "Darrick J . Wong" <djwong@...nel.org>, mcgrof@...nel.org,
 gost.dev@...sung.com, hch@....de, Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: [RFC 0/4] add static huge zero folio support

On 22.07.25 11:42, Pankaj Raghav (Samsung) wrote:
> From: Pankaj Raghav <p.raghav@...sung.com>
> 
> 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.

Please run scripts/checkpatch.pl on your patches.

There are quite some warning for patch #2 and #3, in particular, around 
using spaces vs. tabs.

-- 
Cheers,

David / dhildenb

Powered by blists - more mailing lists