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.

Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
---
Hongfu Li (2):
      mm/hugetlb_cgroup: move per-node usage on cross node migration
      mm/hugetlb_cgroup: move per-node usage on cgroup reparenting

 mm/hugetlb_cgroup.c | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
---
base-commit: baa8de2f3448d1466a888a805c18d01c998fe052
change-id: 20260915-for-hugetlb-charge-2cfada8ed44e

Best regards,
--  
Hongfu Li <lihongfu@kylinos.cn>

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?

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).

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