linux-kernel - Re: [PATCH 1/2 v2] sched: fix find_idlest

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Dec 2016 09:48:56 +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 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.