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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jul 07, 2026 at 07:46:28PM +0100, Lorenzo Stoakes wrote:
> 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.

Oh sure, "fix bugs A,B,C before you add to this mess" is a classic way
to actually not end up with even more of a mess.  But I usually do try
to be explicit of what are specific issues I want submitter to address.
I don't really feel figuring that out 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.

Thanks, I hope the above is specific enough for Sourav.

> 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