RFC v12 rebased on mm-unstable as of Feb 21, 2025

Byungchul Park
2025-02-26T11:33:50Z

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