Re: [RFC PATCH 0/6] mm/hugetlb: Dynamic, NUMA-aware HugePage Cache & Free Page Reporting

[Lorenzo Stoakes <ljs@kernel.org>]

On Tue, Jul 07, 2026 at 10:01:55AM -0400, Michael S. Tsirkin wrote:
> On Tue, Jul 07, 2026 at 12:06:34PM +0100, Lorenzo Stoakes wrote:
> > On Tue, Jul 07, 2026 at 12:28:44PM +0200, David Hildenbrand (Arm) wrote:
> > > On 7/7/26 12:25, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 07, 2026 at 09:29:07AM +0200, David Hildenbrand (Arm) wrote:
> > > >> On 7/7/26 08:42, Sourav Panda wrote:
> > > >>> Overview
> > > >>> This patch series introduces a dynamic, NUMA-aware HugePage Cache,
> > > >>> backed by a kernel shrinker to safely return memory under pressure, and
> > > >>> integrates it with Free Page Reporting (virtio-balloon) for HugeTLB,
> > > >>> specifically targeting gigantic (1GB) hugepages. The goal is to solve
> > > >>> the tradeoff between allocation latency and memory
> > > >>> fungibility in virtualized and heterogeneous cloud environments.
> > > >>
> > > >> Hi,
> > > >>
> > > >> in general, we consider hugetlb nowadays to be mostly in feature freeze, as we
> > > >> realized a while ago that adding more special casing on top of something too
> > > >> special for all of MM is only going to hurt us more in the long run.
> > > >>
> > > >> We want to have less special casing and less special sauce, not more.
> > > >>
> > > >> Now, there is nothing wrong in making hugetlb be less special, by making it use
> > > >> more of core infrastructure etc.
> > > >>
> > > >> But optimizing for surplus hugetlb pages by teaching hugetlb about new caches
> > > >> and its custom free-page-reporting support rather looks like the wrong direction
> > > >> for me?
> > > >>
> > > >> --
> > > >> Cheers,
> > > >>
> > > >> David
> > > >
> > > >
> > > > It is currently bypassing free-page-reporting completely.
> > > > Making existing free lists not ignore free-page-reporting would
> > > > maybe considered "making it be less special"?
> > > >
> >
> > You have this completely backwards.
> >
> > You're advocating making hugetlb _more special_ by duplicating functionality that
> > core mm already supports.
> >
> > I mean:
> >
> > mm/hugetlb.c                                 | 590 ++++++++++++++++++-
> >
> > Tells the whole story right?
> >
> > The whole issue with hugetlb is the very fact that it's a parallel
> > implementation of a bunch of mm stuff in its own little world.
> >
> > We make it less special by mm/hugetlb.c smaller and smaller and implementing
> > what it does sanely elsewhere in _core mm_.
> >
> > >
> > > Depends. We don't really want an orthogonal implementation of something we have
> > > in core-mm.
> >
> > Yes, exactly.
> >
> > Feature freeze means feature freeze, not 'feature that core mm doesn't support
> > feature freeze'.
> >
> > Hugetlb is a poster child for poor decision making in mm that has left us
> > saddled with maintenance nightmares because we allowed 'just one more feature
> > in' (TM) with little to no thought to the future.
> >
> > And we've all learned from that and don't want to repeat these kinds of
> > mistakes, nor make existing mistakes worse.
> >
> > And work to improve hugetlbfs and make changes like the above are VERY welcome
> > :)
>
> Fair enough.
>
> > Laying a foundation for hugetlbfs to be more of a sane mm citizen through rework
> > series is really the asking price for stuff like this in my opinion.
>
> Lorenzo, do you know *how* you want it reworked? Could you write it up
> at a high level?
> Because if not, it's not really practical to make it the asking price.

Michael, you're an experienced maintainer, I'm surprised I have to tell you that
the burden for that lands on the submitter.

Nor does a no from a maintainer require an alternative be provided.

In any case, I felt I was clear above but to reiterate - do the opposite of what
the issues are:

- Implement things in core mm without it being treated as a separate entity.

- Reduce the propagation of if (hugetlb) { ... something specific ... } strewn
  through the code base.

- De-duplicate the appalling parallel implementations — and not by pulling
  things out 'just for hugetlb', but by making it ordinary.

There are a WHOLE HOST of issues and problems and difficulties with doing all of
that. But that's just the reality of it - again, the burden of figuring that out
is on the submitter.

So the price for entry is high, very high, but that doesn't make the no any less
emphatic - we're not going to accept the problem being made any worse.

Note that I'm currently working on reworking the anon rmap which is similarly
problematic. I didn't get nor expect detailed guidelines on how to do so. The
burden's on me, and it's equally a high price to pay.

But setting the bar such that the codebase is as good and robust as it can be
both now and in the future is what maintainership is about.

Thanks, Lorenzo