Re: [PATCH 1/2 v2] sched: fix find_idlest_group for fork

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Nov 29, 2016 at 02:46:10PM +0000, Morten Rasmussen wrote:
> On Tue, Nov 29, 2016 at 12:42:43PM +0100, Peter Zijlstra wrote:
> > 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;
> > > > -

> The last bit that isn't clear to me is whether /512 is a 'large' fuzz
> factor. I guess it is, as we can have many wake-ups, i.e. many times
> avg_cost, over the period where avg_idle is calculated. No?


So the idea was to not spend more time looking for work than we're
actually going to be idle for, since then we're wasting time we could've
done work.

So avg_idle and avg_cost are equal measure in that the immediate
inequality would be: if (avg_idle < avg_cost) stop().

Of course, both being averages with unknown distribution makes that a
tricky proposition, and that also makes the 512 hard to quantify. Still
a factor of 512 of the total average, where our variable cannot go
negative (negative time intervals are nonsensical), is fairly large.