linux-kernel - Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

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: <65cdc2fa-b6ba-4422-9537-feb7d3a33210@kernel.org>
Date: Thu, 15 Jan 2026 21:22:28 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: dan.j.williams@...el.com, Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Li Zhe <lizhe.67@...edance.com>, akpm@...ux-foundation.org,
 ankur.a.arora@...cle.com, fvdl@...gle.com, joao.m.martins@...cle.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, mhocko@...e.com,
 mjguzik@...il.com, muchun.song@...ux.dev, osalvador@...e.de,
 raghavendra.kt@....com, linux-cxl@...r.kernel.org,
 Davidlohr Bueso <dave@...olabs.net>, Gregory Price <gourry@...rry.net>,
 zhanjie9@...ilicon.com, wangzhou1@...ilicon.com
Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

On 1/15/26 21:16, dan.j.williams@...el.com wrote:
> David Hildenbrand (Red Hat) wrote:
> [..]
>>> Give me a list of 1Gig pages and this stuff becomes much more efficient
>>> than anything the CPU can do.
>>
>> Right, and ideally we'd implement any such mechanisms in a way that more
>> parts of the kernel can benefit, and not just an unloved in-memory
>> file-system that most people just want to get rid of as soon as we can :)
> 
> CPUs have tended to eat the value of simple DMA offload operations like
> copy/zero over time.
> 
> In the case of this patch there is no async-offload benefit because
> userspace is already charged with spawning more threads if it wants more
> parallelism.

In this subthread we're discussing handling that in the kernel like 
init_on_free. So when user space frees a hugetlb folio (or in the 
future, other similarly gigantic folios from another allocator), we'd be 
zeroing it.

If it would be freeing multiple such folios, we could pack them and send 
them to a DMA engine to zero them for us (concurrently? asynchronously? 
I don't know :) )

-- 
Cheers

David