From: Yuyang Du <yuyang.du@intel.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <umgwanakikbuti@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: 4.3 group scheduling regression
Date: Mon, 12 Oct 2015 10:12:31 +0800 [thread overview]
Message-ID: <20151012021230.GK11102@intel.com> (raw)
In-Reply-To: <20151012091206.GK3816@twins.programming.kicks-ass.net>
On Mon, Oct 12, 2015 at 11:12:06AM +0200, Peter Zijlstra wrote:
> 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.
Yeah, I thought so.
> I see you've deleted all that code; see the former
> __update_group_entity_contrib().
Probably not there, it actually was an icky way to adjust things.
> 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 :/
I am guessing it is in calc_tg_weight(), and naughty boys do make them more
favored, what a reality...
Mike, beg you test the following?
--
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4df37a4..b184da0 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2370,7 +2370,7 @@ static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq)
*/
tg_weight = atomic_long_read(&tg->load_avg);
tg_weight -= cfs_rq->tg_load_avg_contrib;
- tg_weight += cfs_rq_load_avg(cfs_rq);
+ tg_weight += cfs_rq->load.weight;
return tg_weight;
}
@@ -2380,7 +2380,7 @@ static long calc_cfs_shares(struct cfs_rq *cfs_rq, struct task_group *tg)
long tg_weight, load, shares;
tg_weight = calc_tg_weight(tg, cfs_rq);
- load = cfs_rq_load_avg(cfs_rq);
+ load = cfs_rq->load.weight;
shares = (tg->shares * load);
if (tg_weight)
next prev parent reply other threads:[~2015-10-12 10:01 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-05 21:48 CFS scheduler unfairly prefers pinned tasks paul.szabo
2015-10-06 2:45 ` Mike Galbraith
2015-10-06 10:06 ` paul.szabo
2015-10-06 12:17 ` Mike Galbraith
2015-10-06 20:44 ` paul.szabo
2015-10-07 1:28 ` Mike Galbraith
2015-10-08 8:19 ` Mike Galbraith
2015-10-08 10:54 ` paul.szabo
2015-10-08 11:19 ` Peter Zijlstra
2015-10-10 13:22 ` [patch] sched: disable task group re-weighting on the desktop Mike Galbraith
2015-10-10 14:03 ` kbuild test robot
2015-10-10 14:41 ` Mike Galbraith
2015-10-10 17:01 ` Peter Zijlstra
2015-10-10 17:13 ` Peter Zijlstra
2015-10-11 2:25 ` Mike Galbraith
2015-10-11 17:42 ` 4.3 group scheduling regression Mike Galbraith
2015-10-12 7:23 ` Peter Zijlstra
2015-10-12 7:44 ` Mike Galbraith
2015-10-12 8:04 ` Peter Zijlstra
2015-10-12 0:53 ` Yuyang Du
2015-10-12 9:12 ` Peter Zijlstra
2015-10-12 2:12 ` Yuyang Du [this message]
2015-10-12 10:23 ` Mike Galbraith
2015-10-12 19:55 ` Yuyang Du
2015-10-13 4:08 ` Mike Galbraith
2015-10-12 20:42 ` Yuyang Du
2015-10-13 8:06 ` Peter Zijlstra
2015-10-13 0:35 ` Yuyang Du
2015-10-13 8:10 ` Peter Zijlstra
2015-10-13 0:37 ` Yuyang Du
2015-10-12 11:47 ` Peter Zijlstra
2015-10-12 19:32 ` Yuyang Du
2015-10-13 8:07 ` Peter Zijlstra
2015-10-13 2:22 ` Mike Galbraith
2015-10-12 8:48 ` Mike Galbraith
2015-10-10 20:14 ` [patch] sched: disable task group re-weighting on the desktop paul.szabo
2015-10-11 2:38 ` Mike Galbraith
2015-10-11 9:25 ` paul.szabo
2015-10-11 12:49 ` Mike Galbraith
2015-10-11 19:46 ` paul.szabo
2015-10-12 1:59 ` Mike Galbraith
2015-10-08 14:25 ` CFS scheduler unfairly prefers pinned tasks Mike Galbraith
2015-10-08 21:55 ` paul.szabo
2015-10-09 1:56 ` Mike Galbraith
2015-10-09 2:40 ` Mike Galbraith
2015-10-11 9:43 ` paul.szabo
2015-10-10 3:59 ` Wanpeng Li
2015-10-10 7:58 ` Wanpeng Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151012021230.GK11102@intel.com \
--to=yuyang.du@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=umgwanakikbuti@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.