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

[Sourav Panda]

On Wed, Jul 8, 2026 at 2:16 AM Michael S. Tsirkin <mst@xxxxxxxxxx> wrote:
>
> On Wed, Jul 08, 2026 at 09:26:18AM +0100, Lorenzo Stoakes wrote:
> > On Tue, Jul 07, 2026 at 09:46:14PM +0200, David Hildenbrand (Arm) wrote:
> > > On 7/7/26 21:32, Michael S. Tsirkin wrote:
> > > > 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:
> > > >>>
> > > >>> Fair enough.
> > > >>>
> > > >>>
> > > >>> 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.
> > >
> > > Sometimes it's certainly easier. With things like hugetlb there often just isn't
> > > a feasible way to integrate it nicely into core-mm. It's just too special.
> >
> > Yeah exactly :) once you reach a certain level of 'specialness' it is more like
> > pointing at a flaming trash pile and crying ;)
> >
> > >
> > > --
> > > Cheers,
> > >
> > > David
> >
> > Cheers, Lorenzo
>
> Well as long as I'm not the one being asked to put it out ... it is just
> hard for me to get motivated to do cleanups if there's no actual bug to
> fix, or a feature to develop somewhat proportional in size to the
> cleanup.  But for example, and without calling anything trash, after poking
> at memory-failure.c, *I* want to cry, because either there's multiple
> races, or I just don't understand the code.  Some of these we discussed
> here already.
>
> It seems to boil down to the fact that when people start getting lots of
> these errors they rush out and buy a new system, so hey. But maybe with
> RAM prices spiking it will become less practical. I'll put together an
> email with a list later, maybe.
>

Hi Lorenzo, David, Muchun, and Michael,

Thank you all for the candid feedback :)

Lorenzo, David, Muchun, your points are well taken. I agree that
adding hugetlb caching and shrinker logic to hugetlb goes against your
long-term goal of integrating with core-mm and reducing special
casing.

Michael, taking your advice, I will strictly focus on Free Page
Reporting for Hugepages as that is a regression in the page reporting
infrastructure.

I will send a single, isolated patch that wires up the standard
hugepage_freelists to page reporting.

Let me know if there are any objections to that!

With regards,
Sourav Panda

> --
> MST
>