Messages in this thread | | | Date | Mon, 12 Oct 2015 11:12:06 +0200 | From | Peter Zijlstra <> | Subject | Re: 4.3 group scheduling regression |
| |
On Mon, Oct 12, 2015 at 08:53:51AM +0800, Yuyang Du wrote: > Good morning, Peter. > > On Mon, Oct 12, 2015 at 10:04:07AM +0200, Peter Zijlstra wrote: > > On Mon, Oct 12, 2015 at 09:44:57AM +0200, Mike Galbraith wrote: > > > > > It's odd to me that things look pretty much the same good/bad tree with > > > hogs vs hogs or hogs vs tbench (with top anyway, just adding up times). > > > Seems Xorg+mplayer more or less playing cross group ping-pong must be > > > the BadThing trigger. > > > > Ohh, wait, Xorg and mplayer are _not_ in the same group? I was assuming > > you had your entire user session in 1 (auto) group and was competing > > against 8 manual cgroups. > > > > So how exactly are things configured? > > Hmm... my impression is the naughty boy mplayer (+Xorg) isn't favored, due > to the per CPU group entity share distribution. Let me dig more.
So in the old code we had 'magic' to deal with the case where a cgroup was consuming less than 1 cpu's worth of runtime. For example, a single task running in the group.
In that scenario it might be possible that the group entity weight:
se->weight = (tg->shares * cfs_rq->weight) / tg->weight;
Strongly deviates from the tg->shares; you want the single task reflect the full group shares to the next level; due to the whole distributed approximation stuff.
I see you've deleted all that code; see the former __update_group_entity_contrib().
It could be that we need to bring that back. But let me think a little bit more on this.. I'm having a hard time waking :/
| |