summaryrefslogtreecommitdiff
path: root/rust/helpers/helpers.c
diff options
context:
space:
mode:
authorAaron Lu <ziqianlu@bytedance.com>2025-09-12 11:44:28 +0800
committerPeter Zijlstra <peterz@infradead.org>2025-09-15 09:38:38 +0200
commit0d4eaf8caf8cd633b23e949e2996b420052c2d45 (patch)
tree50ce5ebeff695d2fbda628112c75107bc1502a64 /rust/helpers/helpers.c
parent253b3f587241967a97a971e23b1e2a7d74244fad (diff)
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>
Diffstat (limited to 'rust/helpers/helpers.c')
0 files changed, 0 insertions, 0 deletions