linux-kernel - Re: [RFC PATCH v12 00/26] LUF(Lazy Unmap Flush) reducing tlb numbers over 90%

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: <20250220233710.GB39373@system.software.com>
Date: Fri, 21 Feb 2025 08:37:10 +0900
From: Byungchul Park <byungchul@...com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Dave Hansen <dave.hansen@...el.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, kernel_team@...ynix.com,
	akpm@...ux-foundation.org, ying.huang@...el.com,
	vernhao@...cent.com, mgorman@...hsingularity.net, hughd@...gle.com,
	willy@...radead.org, david@...hat.com, peterz@...radead.org,
	luto@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
	dave.hansen@...ux.intel.com, rjgolo@...il.com
Subject: Re: [RFC PATCH v12 00/26] LUF(Lazy Unmap Flush) reducing tlb numbers
 over 90%

On Thu, Feb 20, 2025 at 04:29:51PM +0100, Vlastimil Babka wrote:
> On 2/20/25 16:15, Dave Hansen wrote:
> > On 2/19/25 21:20, Byungchul Park wrote:
> >> I'm posting the latest version so that anyone can try luf mechanism if
> >> wanted by any chance.  However, I tagged RFC again because there are
> >> still issues that should be resolved to merge to mainline:
> > 
> > I don't see anything fundamentally different here from the last 11
> > versions. I think the entire approach is dangerous and basically makes
> > things impossible to debug. It's not clear that some of the failure
> > scenarios that I've brought up in the past have actually been fixed.
> 
> Yes, and it's still an invasive change to the buddy allocator.

Didn't want.. but admit.

> IIRC at Plumbers the opinion in the audience was that there might be ways to
> improve the batching on unmap to reduce the flushes without such an invasive
> and potentially dangerous change? Has that been investigated?

Sure.  I tried like, by holding those pages not freed until either no
one accesses the interesting pages or memory pressure is high.  However,
unfortunately it was super hard to fix performance degradation by the
number of page reclaim increased due to the unfreed pages.

> Also "Rebase on akpm/mm.git mm-unstable(5a7056135b) as of Nov 22, 2024." is
> very outdated at this point?

Sorry for that.  I will rebase and share.

	Byungchul
> 
> Thanks,
> Vlastimil
> 
> > What I've said here still stands:
> > 
> >> https://lore.kernel.org/all/fab1dd64-c652-4160-93b4-7b483a8874da@intel.com/
> > 
> >> I think tglx would call all of this "tinkering".  The approach to this
> >> series is to "fix" narrow, specific cases that reviewers point out, make
> >> it compile, then send it out again, hoping someone will apply it.
> >> 
> >> So, for me, until the approach to this series changes: NAK, for x86.
> >> Andrew, please don't take this series.  Or, if you do, please drop the
> >> patch enabling it on x86.
> > 
> > I think I'd also like to stop being cc'd on this. If LUF is merged into
> > mainline and proven to work on arm64 or riscv for a year, I'd be happy
> > to take another look at enabling it on x86. I think that's just about
> > the only thing that would make me reconsider.
> >