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]

Message-ID: <4352991a0912151215o33524766p830e7fcbf9f1fc87@mail.gmail.com>
Date:	Tue, 15 Dec 2009 12:15:30 -0800
From:	Salman Qazi <sqazi@...gle.com>
To:	Arjan van de Ven <arjan@...radead.org>
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 14, 2009 at 5:06 PM, Arjan van de Ven <arjan@...radead.org> wrote:
> On Mon, 14 Dec 2009 16:36:20 -0800
> Salman Qazi <sqazi@...gle.com> wrote:
>
>> On Mon, Dec 14, 2009 at 4:19 PM, Arjan van de Ven
>> <arjan@...radead.org> wrote:
>> > On Mon, 14 Dec 2009 15:11:47 -0800
>> > Salman Qazi <sqazi@...gle.com> wrote:
>> >
>> >
>> > I like the general idea, I have one request (that I didn't see
>> > quite in your explanation): Please make sure that all cpus in the
>> > system do their idle injection at the same time, so that memory can
>> > go into power saving mode as well during this time etc etc...
>> >
>>
>> With the current interface, the forced idle percentages on the CPUs
>> are controlled independently.  There's a trade-off here.  If we inject
>
> I'm fine with that... just want to ask that even if we inject different
> percentages, that we inject them for maximum overlap
> (having the memory power in a machine suddenly be half or less is a
> huge step in power, for something, the alignment itself, that does not
> cost much if any extra performance over randomly distributed idle
> insertions)

I think there is a difference in goals here.  Our goal is to free up
power from one machine, so that it can be used elsewhere.  This means
that any power that we save has to be predictably saved.  We have
models that map between CPU time and power usage, that have to account
for the worst case.  So, if we can save some extra power by
opportunistic means, unfortunately we have no way of using that power
elsewhere.

Having said that, energy savings is a worthy goal by itself.  But, we
have to make sure to balance it with performance.

>
>> idle cycles on all the CPU at the same time, our machine
>> responsiveness also degrades: essentially every CPU becomes equally
>> bad for an interactive task to run on.  Our aim at the moment is to
>> try to concentrate the idle cycles on a small set of CPUs, to strive
>> to leave some CPUs where interactive tasks can run unhindered.  But,
>> given a different workload and goals the correct policy may be
>> different.
>
> as long as the tentative portion of the idle time gets injected at the
> same time.. I suspect there can be a decent balance here where most of
> the time we get the full CPU *and* memory savings, while we degrade
> gracefully for the case where we get increasingly more interactive
> activity.

Let me rephrase what you just said to verify that I understand you
correctly:  we should align the enforcement intervals across CPUs and
thereby eagerly inject over the same time period across multiple CPUs.
 If there is no interactive workload then we would get maximal CPU and
memory savings.  If there are interactive tasks, then we just let them
run like we would in the eager injection in original design.

If I understand correctly, then I like your idea.

>
>
>> Simultaneously idling multiple "cores" becomes necessary in the SMT
>> case: as there is no point in idling a single thread, while the other
>> thread is running full tilt.
>
> I can argue the same for package level btw ;)
>
>
>> I think the best approach may be to provide a way to specify the
>> policy from the user space.  Basically let the user decide at what
>> level of CPU hierarchy the forced idle percentages are specified.
>> Then, in the levels below, we simply inject at the same time.
>
> it's not so much about the specification part; per logical cpu is a nice
> place to specify things... as long as we, in the execution part, align
> things up smart.
>
>
>
>
> --
> Arjan van de Ven        Intel Open Source Technology Centre
> For development, discussion and tips for power savings,
> visit http://www.lesswatts.org
>
--
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/