Re: [PATCH 0/2] mm/hugetlb_cgroup: move the per-node usage along with the folio

[Hongfu Li <hongfu.li@linux.dev>]

On 9/17/26 8:53 AM, Andrew Morton wrote:
> On Wed, 16 Sep 2026 16:30:26 +0800 Hongfu Li <hongfu.li@linux.dev> wrote:
>
>> The per-node usage reported by hugetlb.<size>.numa_stat is accounted
>> against folio_nid() in __hugetlb_cgroup_commit_charge() and
>> __hugetlb_cgroup_uncharge_folio(), so it is only correct while a folio
>> stays charged on the same node and in the same hugetlb_cgroup.
>>
>> Two paths move a folio which stays charged, and neither moves the usage
>> with it. hugetlb_cgroup_migrate() only moves the hugetlb_cgroup pointers
>> of a folio migrated to another node, and hugetlb_cgroup_move_parent()
>> only moves the page_counter charges and the hugetlb_cgroup pointer of
>> the folios of a dying cgroup. In both cases the node (or cgroup) which
>> was charged keeps a usage which never goes away, while the node
>> (or cgroup) which ends up uncharging the folio underflows as soon as
>> the folio is freed.
>>
>> Patch 1/2 moves the usage along with the folio on cross node migration,
>> patch 2/2 does the same for the folios a dying cgroup reparents.
> As I understand it, this series affects numa_stat output but has no
> actual runtime effects?

Yes, that's right. The per-node usage[] is only read by
hugetlb_cgroup_read_numa_stat(), so this series only fixes the values
reported in hugetlb.<size>.numa_stat. It has no effect on charging or
limit enforcement, which go through page_counter and are already
handled correctly by hugetlb_cgroup_migrate() and
hugetlb_cgroup_move_parent().

>
> Do you (and maintainers) think that we should fix this in earlier
> kernels?
>
> (I do - a lot of userspace infrastructure makes expensive decisions
> based on this sort of info).

I agree with you that this should go to stable.

Patch 1/2 and Patch 2/2 already carry Fixes: and Cc: stable tags.

-- 
Best regards,
Hongfu