linux-kernel - Re: [PATCH RFC 0/4] Scheduler idle notifiers and users

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]

Message-ID: <20120211153324.GC31887@opensource.wolfsonmicro.com>
Date:	Sat, 11 Feb 2012 15:33:25 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Saravana Kannan <skannan@...eaurora.org>,
	Ingo Molnar <mingo@...e.hu>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Todd Poynor <toddpoynor@...gle.com>,
	Russell King <linux@....linux.org.uk>,
	Nicolas Pitre <nico@...xnic.net>,
	Oleg Nesterov <oleg@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Anton Vorontsov <anton.vorontsov@...aro.org>,
	linaro-kernel@...ts.linaro.org, Mike Chan <mike@...roid.com>,
	Dave Jones <davej@...hat.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	kernel-team@...roid.com, linux-arm-kernel@...ts.infradead.org,
	Arjan Van De Ven <arjan@...radead.org>
Subject: Re: [PATCH RFC 0/4] Scheduler idle notifiers and users

On Sat, Feb 11, 2012 at 03:53:03PM +0100, Peter Zijlstra wrote:
> On Sat, 2012-02-11 at 14:39 +0000, Mark Brown wrote:

> > For step downs this isn't such a big deal as we don't often care if the
> > voltage drops immediately but for step ups it's critical as if the
> > voltage hasn't ramped before the CPU tries to run at the higher
> > frequency the CPU will brown out. 

> Why isn't all this done by micro-controllers, software writes a desired
> state in some machine register (fast), micro-controller sets about
> making it so in an asynchronous way. If it finds the settings have
> changed by the time it reached its former goal, goto 1.

*Something* is going to have to wait for all the steps to take
place, if when frequency scaling you're not particlarly worried about
waiting for the the actual completion of your frequency change then
doing it in the CPU isn't that hard - you just post the request off
elsewhere and let it get on with trying implement whatever the last
request it saw was (along with all the other constraints it's seeing).
Modulo non-trivial implementation issues, of couse.

> Having to actually wait for this in software is quite ridiculous.

Well, it's also not terribly hard.  There's use cases for having this
stuff offloaded but if you're not doing that stuff then why deal with
the complication of designing the hardware?

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)