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

[David Hildenbrand (Arm)]

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"?
> 

Depends. We don't really want an orthogonal implementation of something we have
in core-mm.

-- 
Cheers,

David