LKML Archive on
help / color / mirror / Atom feed
From: Venkatesh Pallipadi <>
To: Dave Jones <>,
	Venkatesh Pallipadi <>,
	linux-kernel <>,
	Andrew Morton <>, Adam Belay <>,
	Shaohua Li <>,
	Len Brown <>
Subject: Re: [PATCH 1/3] Introducing cpuidle: core cpuidle infrastructure
Date: Tue, 13 Feb 2007 05:31:16 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>; from on Mon, Feb 12, 2007 at 08:22:01PM -0500

On Mon, Feb 12, 2007 at 08:22:01PM -0500, Dave Jones wrote:
> On Mon, Feb 12, 2007 at 10:39:25AM -0800, Venkatesh Pallipadi wrote:
>  > 
>  > Introducing 'cpuidle', a new CPU power management infrastructure to manage
>  > idle CPUs in a clean and efficient manner.
>  > cpuidle separates out the drivers that can provide support for multiple types
>  > of idle states and policy governors that decide on what idle state to use
>  > at run time.
>  > A cpuidle driver can support multiple idle states based on parameters like
>  > varying power consumption, wakeup latency, etc (ACPI C-states for example).
>  > A cpuidle governor can be usage model specific (laptop, server,
>  > laptop on battery etc).
>  > Main advantage of the infrastructure being, it allows independent development
>  > of drivers and governors and allows for better CPU power management.
>  > 
>  > A huge thanks to Adam Belay and Shaohua Li who were part of this mini-project
>  > since its beginning and are greatly responsible for this patchset.
> interesting.  Though I wonder about giving admins _more_ knobs to twiddle.
> It took cpufreq a long time to settle down in this area, and typically
> 'ondemand' was the answer in the end for 99.9% of people.   I question the usefulness
> for the whole multiple governors interface, because in the case of cpuidle
> there shouldn't be any real trade-off between one algorithm and another afaics?
> So why can't we just have one, that just 'does the right thing' ?
> The only differentiator that I can think of would be latency, but that seems
> to be a) covered in a different tunable, and b) probably wouldn't affect
> most people enough where it matters.

Agreed. In long term, I think cpuidle will also have one governor that will be
used in most of the cases. But, we have to go through the process of
experimenting with different governors, just like cpufreq and let the best
governor win. I think this interface helps to experiment with new
governors in a non-disruptive way. I mean, any new experiments will not have
side effects on people already using currently established drivers in

Also, one of the things we are looking at is to have ratings for different
drivers and governors (similar to time subsystem), with which we can control
best driver and best governor for a platform from inside the kernel, instead
of depending on admin/init script to do the right thing.

Having said that, I do feel we may need a different governor for things like
handhelds. I heard them saying there idle routines has more than one
dimension of low power-high latency idle states. But, that do not suggest the
need for runtime switch in sysfs, as it will still be one proper governor for
a platform.

> I'll do a proper code review later, but one thing stuck out like a sore
> thumb on a quick skim..
>  > +EXPORT_SYMBOL_GPL(current_driver);
> That's a horribly generic name for an exported global.
> current_cpuidle_driver maybe?

oops. I don't think we need to export here.
Though, name should change to current_cpuidle_driver as it is non-static. Will
fix it in next rev. 


  parent reply	other threads:[~2007-02-13 14:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12 18:39 Venkatesh Pallipadi
2007-02-13  1:22 ` Dave Jones
2007-02-13  7:58   ` Arjan van de Ven
2007-02-13 13:31   ` Venkatesh Pallipadi [this message]
2007-02-14  4:10     ` Adam Belay

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 1/3] Introducing cpuidle: core cpuidle infrastructure' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).