From: Arjan van de Ven <arjan@infradead.org>
To: Salman Qazi <sqazi@google.com>
Cc: linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org,
Andrew Morton <akpm@linux-foundation.org>,
Michael Rubin <mrubin@google.com>,
Taliver Heath <taliver@google.com>
Subject: Re: RFC: A proposal for power capping through forced idle in the Linux Kernel
Date: Mon, 14 Dec 2009 17:06:16 -0800 [thread overview]
Message-ID: <20091214170616.59fc163f@infradead.org> (raw)
In-Reply-To: <4352991a0912141636t35a96c14o5fd4b9e152e6e681@mail.gmail.com>
On Mon, 14 Dec 2009 16:36:20 -0800
Salman Qazi <sqazi@google.com> wrote:
> On Mon, Dec 14, 2009 at 4:19 PM, Arjan van de Ven
> <arjan@infradead.org> wrote:
> > On Mon, 14 Dec 2009 15:11:47 -0800
> > Salman Qazi <sqazi@google.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)
> 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.
> 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
next prev parent reply other threads:[~2009-12-15 1:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-14 23:11 RFC: A proposal for power capping through forced idle in the Linux Kernel Salman Qazi
2009-12-14 23:21 ` Andi Kleen
2009-12-14 23:51 ` tytso
2009-12-15 0:42 ` Salman Qazi
2009-12-22 19:48 ` Peter Zijlstra
2009-12-15 0:19 ` Arjan van de Ven
2009-12-15 0:36 ` Salman Qazi
2009-12-15 1:06 ` Arjan van de Ven [this message]
2009-12-15 20:15 ` Salman Qazi
2009-12-17 11:01 ` Arjan van de Ven
2009-12-15 10:29 ` Vaidyanathan Srinivasan
2009-12-15 11:50 ` Vaidyanathan Srinivasan
2009-12-15 21:00 ` Salman Qazi
2009-12-15 20:50 ` Salman Qazi
2009-12-22 19:48 ` Peter Zijlstra
2009-12-22 19:57 ` Arjan van de Ven
2009-12-18 17:04 ` Pavel Machek
2009-12-22 21:10 ` Salman Qazi
2009-12-23 9:49 ` Pavel Machek
2009-12-21 8:57 ` Pavel Machek
2009-12-22 21:15 ` Salman Qazi
2009-12-23 9:52 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091214170616.59fc163f@infradead.org \
--to=arjan@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=mrubin@google.com \
--cc=sqazi@google.com \
--cc=taliver@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox