]> Gentwo Git Trees - linux/.git/commit
sched/fair: Do not balance task to a throttled cfs_rq
authorAaron Lu <ziqianlu@bytedance.com>
Fri, 12 Sep 2025 03:44:28 +0000 (11:44 +0800)
committerPeter Zijlstra <peterz@infradead.org>
Mon, 15 Sep 2025 07:38:38 +0000 (09:38 +0200)
commit0d4eaf8caf8cd633b23e949e2996b420052c2d45
tree50ce5ebeff695d2fbda628112c75107bc1502a64
parent253b3f587241967a97a971e23b1e2a7d74244fad
sched/fair: Do not balance task to a throttled cfs_rq

When doing load balance and the target cfs_rq is in throttled hierarchy,
whether to allow balancing there is a question.

The good side to allow balancing is: if the target CPU is idle or less
loaded and the being balanced task is holding some kernel resources,
then it seems a good idea to balance the task there and let the task get
the CPU earlier and release kernel resources sooner. The bad part is, if
the task is not holding any kernel resources, then the balance seems not
that useful.

While theoretically it's debatable, a performance test[0] which involves
200 cgroups and each cgroup runs hackbench(20 sender, 20 receiver) in
pipe mode showed a performance degradation on AMD Genoa when allowing
load balance to throttled cfs_rq. Analysis[1] showed hackbench doesn't
like task migration across LLC boundary. For this reason, add a check in
can_migrate_task() to forbid balancing to a cfs_rq that is in throttled
hierarchy. This reduced task migration a lot and performance restored.

[0]: https://lore.kernel.org/lkml/20250822110701.GB289@bytedance/
[1]: https://lore.kernel.org/lkml/20250903101102.GB42@bytedance/

Signed-off-by: Aaron Lu <ziqianlu@bytedance.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
kernel/sched/fair.c