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 for Android: free password hash cracker in your pocket

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

Message-ID: <4352991a0912221315y5ba409cbh26baa5937cdf2f76@mail.gmail.com>
Date:	Tue, 22 Dec 2009 13:15:21 -0800
From:	Salman Qazi <sqazi@...gle.com>
To:	Pavel Machek <pavel@....cz>
Cc:	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>
Subject: Re: RFC: A proposal for power capping through forced idle in the 
	Linux Kernel

On Mon, Dec 21, 2009 at 12:57 AM, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>> Google is implementing power capping, a technology that improves the
>> power efficiency of data centers. There are also some interesting
>> applications of this technology for laptops and cell phones.  Google
>> aims to send most of its Linux technology upstream. So, how can we get
>> this feature into the mainline kernel?
> ...
>> Aside from this, every cgroup has a new quantity added to the CPU
>> component called "Power Capping Priority".  This quantity indicates
>> the order in which the scheduler attributes the time spent injecting
>> idle cycles to specific processes.  This allows us to discriminate
>> among processes when it comes to accounting for the injected idle
>> time.  There is also an indication of interactivity versus batch for
>> the cgroup provided in the CPU component of the cgroup.
>>
>> Basic Algorithm:
>>
>> Rather than blindly blasting the machine with the minimum required
>> idle cycles, our implementation keeps track of naturally occurring
>> idle cycles as follows:
>
> (Rather complex algorithm snipped)
>
> Well.. having all this complexity just for forcing idle... And it
> still will not work, right? Linux kernel is not real time, so you
> can't guarantee anything.

The purpose of all the "complexity" is to avoid injecting idle cycles
when the machine is already sufficiently idle.  That is, to lower the
impact when the feature is not needed.  And you are right, there are
no hard guarantees.  A lot of the practical use will rest on empirical
data.

>
> OTOH realtime people already have tools you could make good use of:
> your power capping approach looks like 'high priority idle task that
> needs to run for 2 seconds every 5 seconds' or something...
>
> Talk to rt people?

At the core of it, you are correct.  However, in our implementation it
also avoids running when the system is already idle and operates at
much finer granularities than seconds.

Which specific tools are you referring to?  Real-time Linux as a whole
is a trade off:  one gets predictable latency in exchange for some
performance.  Any specific contacts that I should direct my inquiries
to?

>                                                                Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
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/