All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: svaidy@linux.vnet.ibm.com
Cc: Andi Kleen <ak@linux.intel.com>,
	Trinabh Gupta <trinabh@linux.vnet.ibm.com>,
	Venkatesh Pallipadi <venki@google.com>,
	peterz@infradead.org, lenb@kernel.org, suresh.b.siddha@intel.com,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC V1] cpuidle: add idle routine registration and cleanup pm_idle pointer
Date: Wed, 20 Oct 2010 12:25:55 -0700	[thread overview]
Message-ID: <4CBF4243.4040104@linux.intel.com> (raw)
In-Reply-To: <20101020191941.GA706@dirshya.in.ibm.com>

  On 10/20/2010 12:19 PM, Vaidyanathan Srinivasan wrote:
> * Arjan van de Ven<arj
> I see this RFC as an incremental step to move all idle routine
> registration functionality into the kernel and keep governors and low
> level drivers as modules.  This will allow non x86 archs with just one
> idle routine to keep minimal overhead.  (Though this is becoming very
> rare).

yes pretty much all embedded really has more idle states, esp arm and co

> As stated in the goal the solution should satisfy the following
> requirements:
>
> 4. Minimal overhead for arch with following use cases
>          a) Single compile time defined idle routine, no need for
>             runtime/boot time selection

you ALWAYS have at least 2 idle handling states. The platform idle one 
and the generic busy waiting one.
the later is needed for "I want absolutely 0 latency" cases.

 > Making current cpuidle as default in kernel

not "in the kernel" but "for x86".
You're solving an x86 problem here, right?
(the pm_idle is an x86 only problem. other architectures should be able 
to keep doing what they are doing)
For x86, lets solve it by going to cpuidle period... and if Andi can 
find some bloat in cpuidle, lets see if the fat can be trimmed.

other architectures can either follow, or if they have nothing special 
and only one idle routine, can do whatever they want.


  reply	other threads:[~2010-10-20 19:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19 18:36 [RFC V1] cpuidle: add idle routine registration and cleanup pm_idle pointer Trinabh Gupta
2010-10-19 18:38 ` Arjan van de Ven
2010-10-19 18:49   ` Venkatesh Pallipadi
2010-10-19 19:01     ` Trinabh Gupta
2010-10-20 15:12       ` Trinabh Gupta
2010-10-20 15:18         ` Arjan van de Ven
2010-10-20 15:34           ` Andi Kleen
2010-10-20 16:03             ` Arjan van de Ven
2010-10-20 19:19               ` Vaidyanathan Srinivasan
2010-10-20 19:25                 ` Arjan van de Ven [this message]
2010-10-20 19:28                   ` Peter Zijlstra
2010-10-20 19:29                     ` Arjan van de Ven
2010-10-20 19:40                   ` Vaidyanathan Srinivasan
2010-10-20 19:44                     ` Arjan van de Ven
2010-10-20 19:47                       ` Venkatesh Pallipadi
2010-10-20 20:03                         ` Vaidyanathan Srinivasan
2010-10-20 20:47                         ` Arjan van de Ven
2010-10-20 21:19                           ` Venkatesh Pallipadi
2010-10-20 20:55               ` Dipankar Sarma
2010-10-20 15:57           ` Trinabh Gupta

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=4CBF4243.4040104@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=ak@linux.intel.com \
    --cc=benh@kernel.crashing.org \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=suresh.b.siddha@intel.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=trinabh@linux.vnet.ibm.com \
    --cc=venki@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 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.