All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Hongfu Li <hongfu.li@linux.dev>
Cc: Oscar Salvador <osalvador@suse.de>,
	David Hildenbrand <david@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kees Cook <kees@kernel.org>,
	Colin Ian King <colin.i.king@gmail.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Mina Almasry <almasrymina@google.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hongfu Li <lihongfu@kylinos.cn>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] mm/hugetlb_cgroup: move per-node usage on cross node migration
Date: Thu, 17 Sep 2026 13:58:11 +0800	[thread overview]
Message-ID: <E35A1286-33DF-4B54-8338-888EE28BFD06@linux.dev> (raw)
In-Reply-To: <20260916-for-hugetlb-charge-v1-1-70fb708b2e4a@kylinos.cn>



> On Sep 16, 2026, at 16:30, Hongfu Li <hongfu.li@linux.dev> wrote:
> 
> From: Hongfu Li <lihongfu@kylinos.cn>
> 
> 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().
> 
> Fixes: f47761999052 ("hugetlb: add hugetlb.*.numa_stat file")
> Cc: stable@vger.kernel.org
> Signed-off-by: Hongfu Li <lihongfu@kylinos.cn>
> ---
> mm/hugetlb_cgroup.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> 
> diff --git a/mm/hugetlb_cgroup.c b/mm/hugetlb_cgroup.c
> index ecb6e0b7819a..1040406e7e1d 100644
> --- a/mm/hugetlb_cgroup.c
> +++ b/mm/hugetlb_cgroup.c
> @@ -179,6 +179,34 @@ static void hugetlb_cgroup_css_free(struct cgroup_subsys_state *css)
> 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 = READ_ONCE(from->nodeinfo[from_nid]->usage[idx]);

READ_ONCE is unnecessary because there is no concurrent writer.

> + 	if (WARN_ON_ONCE(usage < nr_pages))
> + 		return;
> + 	WRITE_ONCE(from->nodeinfo[from_nid]->usage[idx], usage - nr_pages);
> +
> + 	usage = READ_ONCE(to->nodeinfo[to_nid]->usage[idx]);

Same here.

> + 	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 *old_folio, struct folio *new_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);
> }
> 
> -- 
> 2.54.0
> 



  reply	other threads:[~2026-09-17  5:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-16  8:30 [PATCH 0/2] mm/hugetlb_cgroup: move the per-node usage along with the folio Hongfu Li
2026-09-16  8:30 ` [PATCH 1/2] mm/hugetlb_cgroup: move per-node usage on cross node migration Hongfu Li
2026-09-17  5:58   ` Muchun Song [this message]
2026-09-17  9:59     ` Hongfu Li
2026-09-16  8:30 ` [PATCH 2/2] mm/hugetlb_cgroup: move per-node usage on cgroup reparenting Hongfu Li
2026-09-17  6:08   ` Muchun Song
2026-09-17  0:53 ` [PATCH 0/2] mm/hugetlb_cgroup: move the per-node usage along with the folio Andrew Morton
2026-09-17 10:17   ` Hongfu Li

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=E35A1286-33DF-4B54-8338-888EE28BFD06@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=almasrymina@google.com \
    --cc=colin.i.king@gmail.com \
    --cc=david@kernel.org \
    --cc=hongfu.li@linux.dev \
    --cc=kees@kernel.org \
    --cc=lihongfu@kylinos.cn \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --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.