All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@infradead.org>
To: Gregory Haskins <ghaskins@novell.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
	LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: sched: deep power-saving states
Date: Wed, 22 Oct 2008 07:36:16 -0700	[thread overview]
Message-ID: <20081022073616.5eb150fa@infradead.org> (raw)
In-Reply-To: <48FF3829.8040704@novell.com>

On Wed, 22 Oct 2008 10:26:49 -0400
Gregory Haskins <ghaskins@novell.com> wrote:
steps, so it'll be
> > faster) 
> 
> [Adding Peter Zijlstra to the thread]
> 
> Ah, yes of course!   That makes sense.  So I have to admit I am fairly
> ignorant of the ACPI C-state stuff, so I just read up on it.  In the
> context of what you said, it makes perfect sense to me now.
> 
> IIUC, the OS selects which C-state it will enter at idle points based
> on some internal criteria (TBD).  All we have to do is remap the
> cpupri "IDLE" state to something like IDLE-C1, IDLE-C2, ..., IDLE-Cn
> and have the cpupri map get updated coincident with the pm_idle()
> call.  Then the scheduler will naturally favor cores that are in
> lighter sleep over cores in deep sleep.
> 
> I am not sure if this is exactly what you were getting at during the
> conf, since it doesnt really consider deep-sleep latency times
> directly.  But I think this is a step in the right direction.

it for sure is a step in the right direction.
the actual exit costs are an optional parameter in this sense,
the steps between C states are non-linear (more like exponential)
so knowing the actual numbers could be used. but even if you don't
use it, it still makes sense and is a very good first order behavior.



-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

  reply	other threads:[~2008-10-22 14:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-22 13:42 sched: deep power-saving states Gregory Haskins
2008-10-22 13:47 ` Arjan van de Ven
2008-10-22 14:05   ` Gregory Haskins
2008-10-22 14:07     ` Arjan van de Ven
2008-10-22 14:26       ` Gregory Haskins
2008-10-22 14:36         ` Arjan van de Ven [this message]
2008-10-22 19:49           ` Peter Zijlstra
2008-10-22 19:55             ` Arjan van de Ven
2008-10-22 20:05               ` Peter Zijlstra
2008-10-22 20:12                 ` Arjan van de Ven
  -- strict thread matches above, loose matches on Subject: below --
2008-10-22 13:44 Gregory Haskins

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=20081022073616.5eb150fa@infradead.org \
    --to=arjan@infradead.org \
    --cc=ghaskins@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.