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
|  |