Re: [PATCH v3] mm: remove min_free_kbytes adjustment for THP

[Johannes Weiner <hannes@cmpxchg.org>]

On Wed, Sep 02, 2026 at 06:00:55PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Sep 02, 2026 at 12:23:23PM -0400, Johannes Weiner wrote:
> > Just to summarize my take from the subthread with Zi: the premise of
> > this patch is to roll the regression dice on every THP setup out there
> > because certain ARM configurations result in a questionable pageblock size.
> >
> > I'm not against carefully evaluating and testing out today's need for
> > set_recommended_min_free_kbytes() in real world examples. But this is
> > not that.
> >
> > Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
> 
> Well you don't have to listen to me any more as ex-THP M ;) but my 2
> pence...

I'll always listen to you, Lorenzo. <3

> Isn't every possible change to address this kind of issue subject to
> exactly the same kind of constraint?
> 
> I'd like to know what not rolling that dice looks like :) or what
> constitutes 'careful evaluation'.

Usama gave some great examples in his other email. I'm not really
arguing to keep things out of tradition. But I think it's fair to say
let's at least test the common 4k/2M THP setups under memory pressure
before and after the change. Or be more specific about which changes
obviated the additional pageblock reserves, and how.

> It feels like in certain areas we paint ourselves into a corner where
> everybody's too scared to change anything until we're sure nobody in the
> world is broken*.

I'm fine with calculated risks, actually. A bit more surprised that
Michal was so readily on board with this :)

> And so we continue to ride the merry-go-round of proposals/rejections
> indefinitely.
> 
> All the while regressions in tip kernel are a regular occurrence (yes we
> don't want that, but they happen), and they are resolved as they arise.
> 
> I wonder if we aren't limiting ourselves by thinking this way.
> 
> Michal's proposal was that the original code was written _long_ before
> improvements in the compaction algorithm and fails to account for those.
> 
> It seems odd to retain the same constraints given the rest of the kernel
> has changed.

That's a great motivation to take a closer look at whether we still
need it. I'm not attached to anything that's plausibly shown to be
unnecessary.

But I think there are levels of argument quality:

1. This code is old as in time
2. This code is old as in the surroundings have changed
3. This code is not needed due to sha1, sha2, sha3 supplanting it thusly: ...
4. This code is not making a difference in represenative tests

The patch is at 2 and I would really prefer we get to 3 or 4. That's
not the same as saying we should stop making changes.

And honestly, while we tend to claim we want 4 for everything, we're
happy many times to roll the dice at 3 - iff the story is specific and
plausible. And I believe that touches on your footnote ;)

But let's talk about plausible. Because I'm reading what
set_recommended_min_free_kbytes() does, along with its comments, and
can't help but think that this still applies in the current world.

The compaction aid is/was always incidental. Yeah it would suck if
that is/was (still) an implicit dependency, but ridding us of that
could be a more deeper-reaching change than you would want to make to
fix that pressing reserves issue with 64k pages.

The fallback avoidance reasoning OTOH still seems cogent to me. The
mechanism it references is about passive fragmentation avoidance by
giving the allocator placement options, before compaction gets
involved. That makes sense in how I understand page_alloc.c today.

> Perhaps a compromise would be to put the ability to disable this behind a
> config option or maybe a kernel arg? Of course that becomes something of a
> uAPI... but at least it gives the option to constrian this for those who
> want it.

I can't force you to engage with the idea of capping the pageblock
instead. But I'm still kind of dying to know what the reluctance is ;)
And I apologize if I missed any prior arguments on this specifically.