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:	Wed, 20 Feb 2013 09:43:43 +0100
From:	Mike Galbraith <efault@....de>
To:	Alex Shi <alex.shi@...el.com>
Cc:	peterz@...radead.org, Joonsoo Kim <iamjoonsoo.kim@....com>,
	torvalds@...ux-foundation.org, mingo@...hat.com,
	tglx@...utronix.de, akpm@...ux-foundation.org,
	arjan@...ux.intel.com, bp@...en8.de, pjt@...gle.com,
	namhyung@...nel.org, vincent.guittot@...aro.org,
	gregkh@...uxfoundation.org, preeti@...ux.vnet.ibm.com,
	viresh.kumar@...aro.org, linux-kernel@...r.kernel.org,
	morten.rasmussen@....com
Subject: Re: [patch v5 10/15] sched: packing transitory tasks in wake/exec
 power balancing

On Wed, 2013-02-20 at 16:11 +0800, Alex Shi wrote: 
> On 02/20/2013 03:40 PM, Mike Galbraith wrote:
> > On Wed, 2013-02-20 at 13:55 +0800, Alex Shi wrote:
> > 
> >> Joonsoo Kim suggests not packing exec task, since the old task utils is
> >> possibly unuseable.
> > 
> > (I'm stumbling around in rtmutex PI land, all dazed and confused, so
> > forgive me if my peripheral following of this thread is off target;)
> > 
> > Hm, possibly.  Future behavior is always undefined, trying to predict
> > always a gamble... so it looks to me like not packing on exec places a
> > bet against the user, who chose to wager that powersaving will happen
> > and it won't cost him too much, if you don't always try to pack despite
> > any risks.  The user placed a bet on powersaving, not burst performance.
> > 
> > Same for the fork, if you spread to accommodate a potential burst, you
> > bin the power wager, so maybe it's not in his best interest.. fork/exec
> > is common, if it's happening frequently, you'll bin the potential power
> > win frequently, reducing effectiveness, and silently trading power for
> > performance when the user asked to trade performance for a lower
> > electric bill.
> > 
> > Dunno, just a thought, but I'd say for powersaving policy, you have to
> > go just for broke and hope it works out.  You can't know it won't, but
> > you'll toss potential winnings every time you don't roll the dice.
> 
> 
> Sounds reasonable too.
> 
> I have no idea of the of the decision now.
> And guess many guys dislike to use a knob to let user do the choice.

Nobody likes seeing yet more knobs much, automagical is preferred.
Trouble with automagical heuristics usage is that any heuristic will
inevitably get it wrong sometimes, so giving the user control over usage
is IMHO a good thing.. and once we give the user the choice, we must
honor it, else what was the point?

Anyway, fwiw, I liked what I saw test driving the patch set..

> What's your opinions, Peter?

..but maintainer opinions carry more weight than mine, even to me ;-)

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ