RFC v12 rebased on v6.14-rc4

[Byungchul Park <byungchul@sk.com>]

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 v6.14-rc4.

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