On Tue, Jun 03, 2025 at 10:46:06PM +0800, "Chen, Yu C" <yu.c.chen@xxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
