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@xxxxxxxxx/ > > > >> 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. > >
