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: <fc94c383-5788-43c8-beb3-2fd76acae7bd@suse.cz>
Date: Thu, 20 Feb 2025 16:29:51 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: Dave Hansen <dave.hansen@...el.com>, Byungchul Park <byungchul@...com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org
Cc: 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 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.
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?

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

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.
>