linux-kernel - Re: [PATCH v3 4/4] x86/folio_zero

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: <CAGudoHGgTc98cOz1wUHuC-37SRy64iQyK=+d+Qm0oBfoNHSNow@mail.gmail.com>
Date: Thu, 17 Apr 2025 16:06:09 +0200
From: Mateusz Guzik <mjguzik@...il.com>
To: Ankur Arora <ankur.a.arora@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org, 
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org, bp@...en8.de, 
	dave.hansen@...ux.intel.com, hpa@...or.com, mingo@...hat.com, luto@...nel.org, 
	peterz@...radead.org, paulmck@...nel.org, rostedt@...dmis.org, 
	tglx@...utronix.de, willy@...radead.org, jon.grimm@....com, bharata@....com, 
	raghavendra.kt@....com, boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v3 4/4] x86/folio_zero_user: multi-page clearing

On Wed, Apr 16, 2025 at 6:46 AM Ankur Arora <ankur.a.arora@...cle.com> wrote:
> Mateusz Guzik <mjguzik@...il.com> writes:
>
> > On Tue, Apr 15, 2025 at 11:46 PM Ankur Arora <ankur.a.arora@...cle.com> wrote:
> >> Now, you could argue that the situation is less clear for 2MB pages.
> >>
> >
> > Well I was talking about 2MB. ;) I thought it is a foregone conclusion
> > that 1GB pages will be handled with non-temporal stores, but maybe I'm
> > crossing my wires.
>
> Or I am. I agree the situation is less clear for 2MB. I think for the
> immediate neighbourhood we clearly do want temporal.
>
> For the rest, L2 sizes are typically ~2MB or less. While there might be
> latency benefits for caching the rest of the page, there are clear
> negatives to blowing away state that was definitely useful in the
> near past.
>
> Would be good idea to quantify. Not sure what's a good benchmark to
> do that though.
>

L3 are not that great on many CPUs either, so you could argue you are
blown away the real stuff by zeroing a 2MB page.

I slept on it and I think proper evaluation is rather consuming and
tied to faulting more than one page at a time:
https://lore.kernel.org/linux-mm/CAGudoHGY012mwJqtGPUQ9mfQEVF1_otr9NSbbTYi_vazS09-CQ@mail.gmail.com/#t

I don't believe putting that effort in is a hard requirement at this
stage, albeit it would have been most welcome.

I think your patchset is a step in the right direction, even if the
specific policy is to change later.

All that is to say, I think this bit can be disregarded for now. I
definitely don't want to try to hold up the patchset.

cheers


--
Mateusz Guzik <mjguzik gmail.com>