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

[Lorenzo Stoakes (ARM)]

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

Well you don't have to listen to me any more as ex-THP M ;) but my 2
pence...

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

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

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.

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.

--
Cheers, Lorenzo

* I think, for instance, about how the hell we can test changes to the
  compaction algorithm in a way that's sane and acceptable to people?

  Though that is something that really _does_ need it, as it's vastly more
  complicated and impactful than the proposed change here.

  I'm not sure what the answer is really :) ideally we'd have some vast
  farm of machines doing representative workloads with software that does
  careful statistically-signficant analysis of how they perform, but that
  seems rather like a pipe dream.