linux-kernel - Re: RFC: A proposal for power capping through forced idle in the Linux Kernel

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, 14 Dec 2009 16:42:30 -0800
From:	Salman Qazi <sqazi@...gle.com>
To:	tytso@....edu, Andi Kleen <andi@...stfloor.org>,
	Salman Qazi <sqazi@...gle.com>, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michael Rubin <mrubin@...gle.com>,
	Taliver Heath <taliver@...gle.com>, lenb@...nel.org
Subject: Re: RFC: A proposal for power capping through forced idle in the 
	Linux Kernel

On Mon, Dec 14, 2009 at 3:51 PM,  <tytso@....edu> wrote:
> On Tue, Dec 15, 2009 at 12:21:07AM +0100, Andi Kleen wrote:
>> Salman Qazi <sqazi@...gle.com> writes:
>> >
>> > We'd like to get as much of our stuff upstream as we can.  Given that
>> > this is a somewhat sizable chunk of work, it would be impolite of me
>> > to just send out a bunch of patches without hearing the concerns of
>> > the community.  What are your thoughts on our design and what do we
>> > need to change to get this to be more acceptable to the community?  I
>> > also would like to know if there are any existing pieces of
>> > infrastructure that this can utilize.
>>
>> There were a lot of discussions on this a few months ago in context
>> of the ACPI 4 "power aggregator" which is a similar (perhaps
>> slightly less sophisticated) concept.
>>
>> While there was a lot of talk about teaching the scheduler about this
>> the end result was just a driver which just starts real time threads
>> and then idles in them. This is in current mainline.
>>
>> It might be a good idea to review these discussions in the archives.
>
> It should be noted that most of the heat from those discussions was
> over adding the ACPI 4 mechanism to accept requests from the hardware
> platform to add idle cycles in the case of thermal/power emergencies,
> before we had the scheduler improvements to be able to do so in the
> most efficient way possible.  See the description of commit 8e0af5141:
>
>   ACPI 4.0 created the logical "processor aggregator device" as a
>   mechinism for platforms to ask the OS to force otherwise busy
>   processors to enter (power saving) idle.
>
>   The intent is to lower power consumption to ride-out transient
>   electrical and thermal emergencies, rather than powering off the
>   server....
>
>   Vaidyanathan Srinivasan has proposed scheduler enhancements to
>   allow injecting idle time into the system. This driver doesn't
>   depend on those enhancements, but could cut over to them when they
>   are available.
>
>   Peter Z. does not favor upstreaming this driver until the those
>   scheduler enhancements are in place. However, we favor upstreaming
>   this driver now because it is useful now, and can be enhanced over
>   time.
>
> It looks to me that scheme that Salman has proposed for adding idle
> cycles is quite sophisticated, probably more than Vaidyanathan's, and
> the main difference is that Google wants the ability to be able to
> control the system's power/thermal envelope from userspace, as opposed
> to letting the hardware request in an emergency situation.  This makes
> sense, if you are trying to balance the power/thermal requirements
> across a large number of systems, as opposed to responding to a local
> power/thermal emergency signalled from the platform's firmware.
>

This is correct.  The source of our signal is user space software on
remote machines ("hierarchical regulators") that have information
about power usage across multiple machines at various levels of power
hierarchy.  This is ultimately delivered to a local daemon, which
communicates it to the kernel.

As we are not using this as an emergency measure, we are very
concerned about the performance implications.

> So it would seem to me that Salman's suggestions are very similar to
> what Peter requested before this commit went in (over his objections).
>
> Regards,
>
>                                                - Ted
>
>
--
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/