linux-kernel - Re: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bb57ac40-5579-455f-be79-f0e373d5569d@redhat.com>
Date: Thu, 22 May 2025 14:01:27 +0200
From: David Hildenbrand <david@...hat.com>
To: Mike Rapoport <rppt@...nel.org>, Pankaj Raghav <p.raghav@...sung.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
 Ryan Roberts <ryan.roberts@....com>, 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>, 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>,
 linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 "Darrick J . Wong" <djwong@...nel.org>, gost.dev@...sung.com,
 kernel@...kajraghav.com, hch@....de, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, willy@...radead.org, x86@...nel.org, mcgrof@...nel.org
Subject: Re: [RFC v2 0/2] add THP_HUGE_ZERO_PAGE_ALWAYS config option

On 22.05.25 13:31, Mike Rapoport wrote:
> Hi Pankaj,
> 
> On Thu, May 22, 2025 at 11:02:41AM +0200, Pankaj Raghav wrote:
>> 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.
>>
>> But to use huge_zero_folio, we need to pass a mm struct and the
>> put_folio needs to be called in the destructor. This makes sense for
>> systems that have memory constraints but for bigger servers, it does not
>> matter if the PMD size is reasonable (like x86).
>>
>> Add a config option THP_HUGE_ZERO_PAGE_ALWAYS that will always allocate
>> the huge_zero_folio, and it will never be freed. This makes using the
>> huge_zero_folio without having to pass any mm struct and a call to put_folio
>> in the destructor.
> 
> I don't think this config option should be tied to THP. It's perfectly
> sensible to have a configuration with HUGETLB and without THP.

Such configs are getting rarer ...

I assume we would then simply reuse that page from THP code if available?

-- 
Cheers,

David / dhildenb