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] [day] [month] [year] [list]

Message-ID: <aW_dEjSr4E4N5Fn7@gourry-fedora-PF4VCD3F>
Date: Tue, 20 Jan 2026 14:52:50 -0500
From: Gregory Price <gourry@...rry.net>
To: David Laight <david.laight.linux@...il.com>
Cc: Li Zhe <lizhe.67@...edance.com>, akpm@...ux-foundation.org,
	ankur.a.arora@...cle.com, dan.j.williams@...el.com,
	dave@...olabs.net, david@...nel.org, fvdl@...gle.com,
	joao.m.martins@...cle.com, jonathan.cameron@...wei.com,
	linux-cxl@...r.kernel.org, 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,
	wangzhou1@...ilicon.com, zhanjie9@...ilicon.com
Subject: Re: [PATCH v2 0/8] Introduce a huge-page pre-zeroing mechanism

On Tue, Jan 20, 2026 at 07:30:27PM +0000, David Laight wrote:
> > /* Run programs in serial */
> > sh:  program_a && program_b
> > 
> > in zero_on_alloc():
> > 	program_a eats zero(10) cost on startup
> > 	program_b eats zero(5) cost on startup
> > 	Overall zero(15) cost to start program_b
> > 
> > in zero_on_free()
> > 	program_a eats zero(10) cost on startup
> 
> Do you get that cost? - wont all the unused memory be zeros.
> 

If program_a was the first to access, wouldn't it have had to zero it?

> > But just trivially, starting from the base case of no pages being
> > zeroed, you're just injecting an additional zero(X) cost if program_a()
> > consumes more hugepages than program_b().
> 
> I'd consider a different test:
> 	for c in $(jot 1 1000); do program_a; done
> 
> Regardless of whether you zero on alloc or free all the zeroing is in line.
> Move it to a low priority thread (that uses a non-aggressive loop) and
> there will be reasonable chance of there being pre-zeroed pages available.
> (Most DMA is far too aggressive...)
> 
> If you zero on free it might also be a waste of time.
> Maybe the memory is next used to read data from a disk file.
> 

Right, both points here being that it's heuristic-y, it only applies in
certain scenarios and trying to optimize for one probably hurts another.

~Gregory