linux-kernel - Re: [PATCH v5 2/2] sched/numa: add statistics of numa balance task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <h4chrmiscs66vwl4icda2emof4pbhqabpkklpql2azc5iujilm@o2ttlcanwztc>
Date: Tue, 17 Jun 2025 11:30:19 +0200
From: Michal Koutný <mkoutny@...e.com>
To: "Chen, Yu C" <yu.c.chen@...el.com>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, peterz@...radead.org, 
	akpm@...ux-foundation.org, mingo@...hat.com, tj@...nel.org, hannes@...xchg.org, 
	corbet@....net, mgorman@...e.de, mhocko@...nel.org, muchun.song@...ux.dev, 
	roman.gushchin@...ux.dev, tim.c.chen@...el.com, aubrey.li@...el.com, libo.chen@...cle.com, 
	kprateek.nayak@....com, vineethr@...ux.ibm.com, venkat88@...ux.ibm.com, ayushjai@....com, 
	cgroups@...r.kernel.org, linux-doc@...r.kernel.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, yu.chen.surf@...mail.com
Subject: Re: [PATCH v5 2/2] sched/numa: add statistics of numa balance task

On Tue, Jun 03, 2025 at 10:46:06PM +0800, "Chen, Yu C" <yu.c.chen@...el.com> wrote:
> My understanding is that the "misplaced" container is not strictly tied
> to set_mempolicy or cpuset configuration, but is mainly caused by the
> scheduler's generic load balancer.

You are convincing me with this that, cpu.stat fits the concept better.
Doesn't that sound like that to you?

> Regarding the threaded subtrees mode, I was previously unfamiliar with
> it and have been trying to understand it better.

No problem.

> If I understand correctly, if threads within a single process are
> placed in different cgroups via cpuset, we might need to scan
> /proc/<PID>/sched to collect NUMA task migration/swap statistics.

The premise of your series was that you didn't want to do that :-)

> I agree with your prior point that NUMA balancing task activity is not
> directly
> associated with either the Memory controller or the CPU controller. Although
> showing this data in cpu.stat might seem more appropriate, we expose it in
> memory.stat due to the following trade-offs(or as an exception for
> NUMA balancing):
> 
> 1.It aligns with existing NUMA-related metrics already present in
> memory.stat.

That one I'd buy into. OTOH, I'd hope this could be overcome with
documentation.

> 2.It simplifies code implementation.

I'd say that only applies when accepting memory.stat as the better
place. I think the appropriately matching API should be picked first and
implementation is only secondary to that.
From your reasoning above, I think that the concept is closer to be in
cpu.stat ¯\_(ツ)_/¯

Michal

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)