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: <69694b06835e_34d2a100b3@dwillia2-mobl4.notmuch>
Date: Thu, 15 Jan 2026 12:16:06 -0800
From: <dan.j.williams@...el.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, 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>, Dan Williams
	<dan.j.williams@...el.com>, <zhanjie9@...ilicon.com>,
	<wangzhou1@...ilicon.com>
Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

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.

For sync-offload one engine may be able to beat a single CPU, but now
you have created bandwidth contention problems with a component that is
less responsive to the scheduler.

Call me skeptical.

Signed, someone with async_tx and dmaengine battle scars.