Re: [PATCH 1/2] mm/hugetlb: account migration target folio in per-node NR_HUGETLB vmstat

[Muchun Song]

> On Sep 22, 2026, at 06:35, Joshua Hahn <joshua.hahnjy@xxxxxxxxx> wrote:
> 
> On Mon, 21 Sep 2026 17:12:34 +0800 Hongfu Li <hongfu.li@xxxxxxxxx> wrote:
> 
> Hi Hongfu,
> 
> Thanks for this fix. From the cover letter I was frowning because I was
> thinking to myself "surely there's no way hugetlb accounting is this
> broken..." but it seems like indeed it is. 
> 
>> From: Hongfu Li <lihongfu@xxxxxxxxxx>
>> 
>> The NR_HUGETLB vmstat counter is maintained per folio's node: incremented
>> when a huge page is handed to a user via hugetlb_alloc_folio() and
>> decremented when it is returned to the pool via free_huge_folio().
>> 
>> A folio obtained by alloc_hugetlb_folio_nodemask() never goes through
>> hugetlb_alloc_folio(), so it is never accounted, while its free always
>> is.
> 
> That's pretty scary! Glad that you caught it here.
> 
>> For a migration target this means the target node gets no matching
>> increment for the decrement on the old node, so the global nr_hugetlb in
>> /proc/vmstat drops by nr_pages for each migration. The same asymmetry
>> affects the failed migration path, which frees the target again right
>> away, and the temporary folio hugetlb_mfill_atomic_pte() takes from the
>> same helper.
>> 
>> alloc_hugetlb_folio_reserve(), used to preallocate the memfd page cache
>> folios, has the same asymmetry: the folio is handed to a user without
>> being accounted, while its free is accounted through free_huge_folio().
>> 
>> Account the folio where it is obtained, in alloc_hugetlb_folio_nodemask()
>> and alloc_hugetlb_folio_reserve(), so that the increment pairs with the
>> decrement in free_huge_folio(): a successful migration hands the folio
>> to a user, a failed one frees it again.
> 
> The changes look good to me, and I was able to reproduce the issue on
> my host and confirm that after this change, the missing charge is
> fully accounted for.
> Tested-by: Joshua Hahn <joshua.hahnjy@xxxxxxxxx>
> Reviewed-by: Joshua Hahn <joshua.hahnjy@xxxxxxxxx>
> 
> Again, I'm super surprised that a problem this big has gone unnoticed
> for so long. Thanks again for working on this fix!

I think a migration for HugeTLB is very rare. That's probably why it
took us so long to find this issue.

Thanks.

> 
> I hope you have a great day : -)
> Joshua
> 
>> Fixes: 05d4532b60e3 ("memcg/hugetlb: add hugeTLB counters to memcg")
>> Cc: stable@xxxxxxxxxxxxxxx
>> Signed-off-by: Hongfu Li <lihongfu@xxxxxxxxxx>
>> ---