[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161129114243.GF3092@twins.programming.kicks-ass.net>
Date: Tue, 29 Nov 2016 12:42:43 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Morten Rasmussen <morten.rasmussen@....com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>, mingo@...nel.org,
linux-kernel@...r.kernel.org, matt@...eblueprint.co.uk,
dietmar.eggemann@....com, kernellwp@...il.com, yuyang.du@...el.com,
umgwanakikbuti@...il.com
Subject: Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork
On Tue, Nov 29, 2016 at 10:57:59AM +0000, Morten Rasmussen wrote:
> > @@ -5708,13 +5708,6 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
> >
> > avg_cost = this_sd->avg_scan_cost;
> >
> > - /*
> > - * Due to large variance we need a large fuzz factor; hackbench in
> > - * particularly is sensitive here.
> > - */
> > - if ((avg_idle / 512) < avg_cost)
> > - return -1;
> > -
> > time = local_clock();
> >
> > for_each_cpu_wrap(cpu, sched_domain_span(sd), target, wrap) {
>
> I don't quite get this fix, but it is very likely because I haven't paid
> enough attention.
>
> Are you saying that removing the avg_cost check is improving hackbench
> performance? I thought it was supposed to help hackbench? I'm confused
> :-(
IIRC, and my pounding head really doesn't remember much, the comment
reads like we need the large fudge factor because hackbench. That is,
hackbench would like this test to go away, but others benchmarks will
tank.
Now, if only I would've written down which benchmarks that were.. awell.
Powered by blists - more mailing lists