public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dario Faggioli <raistlin@linux.it>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Harald Gustafsson <hgu1972@gmail.com>,
	Harald Gustafsson <harald.gustafsson@ericsson.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Claudio Scordino <claudio@evidence.eu.com>,
	Michael Trimarchi <trimarchi@retis.sssup.it>,
	Fabio Checconi <fabio@gandalf.sssup.it>,
	Tommaso Cucinotta <cucinotta@sssup.it>,
	Juri Lelli <juri.lelli@gmail.com>
Subject: Re: [PATCH 1/3] Added runqueue clock normalized with cpufreq
Date: Fri, 17 Dec 2010 19:44:54 +0100	[thread overview]
Message-ID: <1292611494.2697.58.camel@Palantir> (raw)
In-Reply-To: <alpine.LFD.2.00.1012171630330.12146@localhost6.localdomain6>

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Fri, 2010-12-17 at 16:43 +0100, Thomas Gleixner wrote: 
> There's that and I have yet to see a proof that running code with
> lower frequency and not going idle saves more power than running full
> speed and going into low power states for longer time.
> 
I was expecting a reply like this from right from you! :-P

BTW, I mostly agree that race to idle is better. The point here is that
you might end in a situation where frequency scaling is enabled and/or
a particular frequency is statically selected for whatever reason. In
that case, making the scheduler aware of such could be needed to get the
expected behaviour out of it, independently from the fact it is probably
going to be worse than race-to-idle for power saving purposes... How
much am I wrong?

> Also if you want to have your deadline scheduler aware of cpu
> frequency changes, then simply limit the total bandwith based on the
> lowest possible frequency and it works always. 
>
That could be a solution as well, although you're limiting a lot the
bandwidth available for deadline task. But something similar could be
considered...

> This whole dynamic
> bandwith expansion is more an academic exercise than a practical
> necessity.
> 
Well, despite the fact that Harald is with Ericsson and as not much to
do with academia. :-D

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
----------------------------------------------------------------------
Dario Faggioli, ReTiS Lab, Scuola Superiore Sant'Anna, Pisa  (Italy)

http://retis.sssup.it/people/faggioli -- dario.faggioli@jabber.org

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2010-12-17 18:43 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-17 13:02 [PATCH 1/3] Added runqueue clock normalized with cpufreq Harald Gustafsson
2010-12-17 13:02 ` [PATCH 2/3] cpufreq normalized runtime to enforce runtime cycles also at lower frequencies Harald Gustafsson
2010-12-17 13:02 ` [PATCH 3/3] sched trace updated with normalized clock info Harald Gustafsson
2010-12-17 14:29 ` [PATCH 1/3] Added runqueue clock normalized with cpufreq Peter Zijlstra
2010-12-17 14:32   ` Peter Zijlstra
2010-12-17 15:06     ` Harald Gustafsson
2010-12-17 15:16       ` Peter Zijlstra
2010-12-17 15:36         ` Harald Gustafsson
2010-12-17 15:43         ` Thomas Gleixner
2010-12-17 15:54           ` Harald Gustafsson
2010-12-17 18:44           ` Dario Faggioli [this message]
2011-01-03 14:17           ` Pavel Machek
2010-12-17 15:02   ` Harald Gustafsson
2010-12-17 18:48     ` Dario Faggioli
2010-12-17 18:56   ` Dario Faggioli
2010-12-17 18:59     ` Peter Zijlstra
2010-12-17 19:16       ` Dario Faggioli
2010-12-17 19:31       ` Harald Gustafsson
2010-12-20  0:11         ` Tommaso Cucinotta
2010-12-20  9:44           ` Harald Gustafsson
2011-01-03 20:25             ` Tommaso Cucinotta
2011-01-04 12:16               ` Harald Gustafsson
2010-12-17 19:27     ` Harald Gustafsson

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=1292611494.2697.58.camel@Palantir \
    --to=raistlin@linux.it \
    --cc=claudio@evidence.eu.com \
    --cc=cucinotta@sssup.it \
    --cc=fabio@gandalf.sssup.it \
    --cc=harald.gustafsson@ericsson.com \
    --cc=hgu1972@gmail.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=trimarchi@retis.sssup.it \
    /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