Messages in this thread Patch in this message | | | From | 王贇 <> | Subject | [RFC PATCH] sched: fix the nonsense shares when load of cfs_rq is too, small | Date | Tue, 3 Mar 2020 22:17:03 +0800 |
| |
During our testing, we found a case that shares no longer working correctly, the cgroup topology is like:
/sys/fs/cgroup/cpu/A (shares=102400) /sys/fs/cgroup/cpu/A/B (shares=2) /sys/fs/cgroup/cpu/A/B/C (shares=1024)
/sys/fs/cgroup/cpu/D (shares=1024) /sys/fs/cgroup/cpu/D/E (shares=1024) /sys/fs/cgroup/cpu/D/E/F (shares=1024)
The same benchmark is running in group C & F, no other tasks are running, the benchmark is capable to consumed all the CPUs.
We suppose the group C will win more CPU resources since it could enjoy all the shares of group A, but it's F who wins much more.
The reason is because we have group B with shares as 2, which make the group A 'cfs_rq->load.weight' very small.
And in calc_group_shares() we calculate shares as:
load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); shares = (tg_shares * load) / tg_weight;
Since the 'cfs_rq->load.weight' is too small, the load become 0 in here, although 'tg_shares' is 102400, shares of the se which stand for group A on root cfs_rq become 2.
While the se of D on root cfs_rq is far more bigger than 2, so it wins the battle.
This patch add a check on the zero load and make it as MIN_SHARES to fix the nonsense shares, after applied the group C wins as expected.
Signed-off-by: Michael Wang <yun.wang@linux.alibaba.com> --- kernel/sched/fair.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 84594f8aeaf8..53d705f75fa4 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -3182,6 +3182,8 @@ static long calc_group_shares(struct cfs_rq *cfs_rq) tg_shares = READ_ONCE(tg->shares);
load = max(scale_load_down(cfs_rq->load.weight), cfs_rq->avg.load_avg); + if (!load && cfs_rq->load.weight) + load = MIN_SHARES;
tg_weight = atomic_long_read(&tg->load_avg);
-- 2.14.4.44.g2045bb6
| |