linux-kernel - Re: [PATCH 2/3] sched: idle: Add sched balance option

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:	Tue, 29 Apr 2014 11:50:02 +0100
From:	Morten Rasmussen <morten.rasmussen@....com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Amit Kucheria <amit.kucheria@...aro.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Ingo Molnar <mingo@...e.hu>,
	Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/3] sched: idle: Add sched balance option

On Sun, Apr 27, 2014 at 02:23:24PM +0100, Rafael J. Wysocki wrote:
> Still, I have a rather fundamental problem with the notion that performance
> and energy efficiency are essentially at odds with each other, because quite
> often they aren't.  What is good for performance is often good for energy
> efficiency as well (like when it may be better to do a certain amount of work
> quickly and then go idle instead of slowing down and taking more time to do
> the work, because that time may turn out to be so long that energy used for
> doing the work will actually be greater).  So while I'm all for acting on power
> events, I'm also for being rather careful with that.

As I wrote in my other reply in this thread, IMO we should distinguish
between objectives and methods to optimize for objectives. Performance
and energy efficiency are different objectives, but some methods might
be useful for optimizing for both (such as race to idle in some
scenarios on some platforms). Tuning knobs and power events shouldn't be
assumed to directly control specific scheduling decisions, for example
whether to race to idle or not. They should only mean that the scheduler
should optimize for a specific goal. For example, a specific
energy/performance trade-off.

> Moreover, in fact performance and energy efficiency are not the only factors
> that need to be taken into account, there also is the maximum power draw (ie.
> the rate of using energy) that can be sustained.  Arguably, all three of them
> always matter, regardless of whether or not the system is on battery.
> 
> People often mentally translate energy efficiency into battery life, because
> that's probably the most obvious case, but in fact it generally translates into
> the cost of doing work (in therms of money or other things).  Going to battery
> means something like "energy is now more valuable to me", but there may be other
> events meaning the same (for example, energy may be cheaper in the night etc).
> So it looks like we need a global mechanism to represent the current relative
> value of energy to the user and to update it whenever something like "we're on
> battery now" happens (other subsystems would benefit from that too IMO).
> 
> The same applies to the maximum sustainable power draw limit more or less.
> While it generally changes between "on battery" and "on AC power", it may also
> depend on other factors like the capacity of the available power supply for a
> data center.

I haven't given maximum power draw much thought, but it is a third
objective independent of energy efficiency even though methods for
improving energy efficiency (such as disabling expensive DVFS states)
might be useful for this as well.
--
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/