From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,stable@vger.kernel.org,shakeel.butt@linux.dev,osalvador@suse.de,muchun.song@linux.dev,kees@kernel.org,david@kernel.org,colin.i.king@gmail.com,almasrymina@google.com,lihongfu@kylinos.cn,akpm@linux-foundation.org
Subject: + mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration.patch added to mm-new branch
Date: Thu, 17 Sep 2026 20:49:08 -0700 [thread overview]
Message-ID: <20260918034908.EAD271F00893@smtp.kernel.org> (raw)
The patch titled
Subject: mm/hugetlb_cgroup: move per-node usage on cross node migration
has been added to the -mm mm-new branch. Its filename is
mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration.patch
This patch will later appear in the mm-new branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews. Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.
The mm-new branch of mm.git is not included in linux-next
If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Hongfu Li <lihongfu@kylinos.cn>
Subject: mm/hugetlb_cgroup: move per-node usage on cross node migration
Date: Fri, 18 Sep 2026 10:56:10 +0800
Patch series "mm/hugetlb_cgroup: move the per-node usage along with the
folio", v3.
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.
This patch (of 2):
hugetlb.<size>.numa_stat uses folio_nid() to account usage in
__hugetlb_cgroup_commit_charge() and __hugetlb_cgroup_uncharge_folio().
hugetlb_cgroup_migrate() only moves hugetlb_cgroup pointers, leaving
per-node usage behind on the source node during cross-node migration.
When the migrated folio gets uncharged, we subtract usage from the
destination node counter. This creates stale usage on the source node and
unsigned long counter underflow on the destination node. The
hugetlb.<size>.numa_stat interface exposes these incorrect per-node usage
values to userspace.
Add a hugetlb_cgroup_move_usage() helper which moves the usage from the
old node to the new node, and call it from hugetlb_cgroup_migrate().
Link: https://lore.kernel.org/20260918-for-hugetlb-charge-v2-0-2b6d8c2bdc36@kylinos.cn
Link: https://lore.kernel.org/20260918-for-hugetlb-charge-v2-1-2b6d8c2bdc36@kylinos.cn
Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file")
Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Muchun Song <muchun.song@linux.dev>
Cc: Colin Ian King <colin.i.king@gmail.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Hongfu Li <lihongfu@kylinos.cn>
Cc: Kees Cook <kees@kernel.org>
Cc: Mina Almasry <almasrymina@google.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: <stable@vger.kernel.org>
---
mm/hugetlb_cgroup.c | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
--- a/mm/hugetlb_cgroup.c~mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration
+++ a/mm/hugetlb_cgroup.c
@@ -179,6 +179,34 @@ static void hugetlb_cgroup_css_free(stru
hugetlb_cgroup_free(hugetlb_cgroup_from_css(css));
}
+static void hugetlb_cgroup_move_usage(struct hugetlb_cgroup *from,
+ struct hugetlb_cgroup *to,
+ struct folio *from_folio,
+ struct folio *to_folio)
+{
+ int idx = hstate_index(folio_hstate(from_folio));
+ unsigned long nr_pages = folio_nr_pages(from_folio);
+ int from_nid = folio_nid(from_folio);
+ int to_nid = folio_nid(to_folio);
+ unsigned long usage;
+
+ lockdep_assert_held(&hugetlb_lock);
+
+ if (!from || !to)
+ return;
+
+ if (from == to && from_nid == to_nid)
+ return;
+
+ usage = from->nodeinfo[from_nid]->usage[idx];
+ if (WARN_ON_ONCE(usage < nr_pages))
+ return;
+ WRITE_ONCE(from->nodeinfo[from_nid]->usage[idx], usage - nr_pages);
+
+ usage = to->nodeinfo[to_nid]->usage[idx];
+ WRITE_ONCE(to->nodeinfo[to_nid]->usage[idx], usage + nr_pages);
+}
+
/*
* Should be called with hugetlb_lock held.
* Since we are holding hugetlb_lock, pages cannot get moved from
@@ -906,6 +934,9 @@ void hugetlb_cgroup_migrate(struct folio
/* move the h_cg details to new cgroup */
set_hugetlb_cgroup(new_folio, h_cg);
set_hugetlb_cgroup_rsvd(new_folio, h_cg_rsvd);
+
+ hugetlb_cgroup_move_usage(h_cg, h_cg, old_folio, new_folio);
+
list_move(&new_folio->lru, &h->hugepage_activelist);
spin_unlock_irq(&hugetlb_lock);
}
_
Patches currently in -mm which might be from lihongfu@kylinos.cn are
mm-use-a-folio-in-the-softleaf_is_device_private-path.patch
mm-hugetlb-fix-resv_huge_pages-double-decrement-in-memfd-error-path.patch
mm-memcontrol-remove-unused-memcg-parameter-in-calculate_high_delay.patch
selftests-mm-khugepaged-consolidate-error-exits-via-kselftest-helpers.patch
mm-page_owner-preserve-original-free_pid-free_tgid-during-folio-migration.patch
mm-memfd-fix-hugetlb-reservation-accounting-in-error-paths.patch
selftests-mm-fix-ptrace-peekdata-check-in-memfd_secret-test.patch
mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration.patch
mm-hugetlb_cgroup-move-per-node-usage-on-cgroup-reparenting.patch
next reply other threads:[~2026-09-18 3:49 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 3:49 Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-09-18 21:40 + mm-hugetlb_cgroup-move-per-node-usage-on-cross-node-migration.patch added to mm-new branch Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260918034908.EAD271F00893@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=colin.i.king@gmail.com \
--cc=david@kernel.org \
--cc=kees@kernel.org \
--cc=lihongfu@kylinos.cn \
--cc=mm-commits@vger.kernel.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=shakeel.butt@linux.dev \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.