Messages in this thread | | | Date | Mon, 17 Nov 2008 23:33:05 -0800 | Subject | Re: busted CFS group load balancer? | From | Ken Chen <> |
| |
On Mon, Nov 17, 2008 at 9:19 PM, Peter Zijlstra wrote: > Note that with larger cpu count and/or lower group weight we'll quickly > run into numerical trouble... > > I would recommend trying this with the minimum weight in the order of > 8-16 times number of cpus on your system. > > There is only so much one can do with 10 bit fixed precision math :/
That is probably one of the many problems. I also found that the updates to the per-cpu task_group's sched_entity load weight (tg->se[cpu]->load.weight) is very problematic and very erratic.
The total rq_weight is calculated at one beginning of tg_shares_up(),
for_each_cpu_mask(i, sd->span) { rq_weight += tg->cfs_rq[i]->load.weight; shares += tg->cfs_rq[i]->shares; }
However, the scaling of per-cpu se->load.weight in function __update_group_shares_cpu() takes another lookup of tg->cfs_rq[cpu]->load.weight at a different time. cfs_rq[cpu].load.weight aren't always consistent across these two times. Due to these inconsistency of value taken on per cpu cfs_rq, I've see tg->se[cpu]->load.weight jumping all over the place. In our environment, the cpu loads are very dynamic. Process queuing/dequeuing at high rate.
I'm also very troubled with this calculation in __update_group_shares_cpu():
shares = (sd_shares * rq_weight) / (sd_rq_weight + 1);
Won't you have rounding problem here? value 'shares' will gradually decrease for each iteration of __update_group_shares_cpu()?
- Ken
| |