On Fri, Feb 21, 2025 at 08:37:10AM +0900, Byungchul Park wrote: > 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. This is the same patch set but rebased on akpm/mm.git mm-unstable(f7ed46277aa) as of Feb 21, 2025. Byungchul > 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. > > >
