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

["David Hildenbrand (Arm)" <david@kernel.org>]

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