From: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
To: Venkatesh Pallipadi <venki@google.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
Trinabh Gupta <trinabh@linux.vnet.ibm.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: Thu, 21 Oct 2010 01:33:21 +0530 [thread overview]
Message-ID: <20101020200321.GC706@dirshya.in.ibm.com> (raw)
In-Reply-To: <AANLkTimNWYuP0e03xTq4Yg7Sb1RPHsQjC2X4wpf1CcPB@mail.gmail.com>
* Venkatesh Pallipadi <venki@google.com> [2010-10-20 12:47:22]:
> >> Ok, you are suggesting that for x86 lets move cpuidle in kernel
> >> always, while it can be an optional module for other archs as it
> >> stands today. We can slim down the cpuidle from current 7K or atleast
> >> split some parts like governors as modules if needed.
> >
> > governors as modules is a total pain. modules don't solve the problem.
> > really. it's still code you need.
> > we have two governors today, menu and ladder
> > menu is best on anything that is tickless
> > ladder is useless on any tickless kernel, and likely not better than menu on
> > non-tickless.
> > that's it.
> > It will be good to have other archs also follow the same cpuidle
>
> I don't think they have to be modules. There can be a CPUIDLE_LITE
> which deCONFIG entire governor.c and individual governors (and
> probably sysfs stuff as well) for archs that can only use one state at
> any time, but still want to do config or runtime detection of one
> state and register that state.
hmm, CPUIDLE_LITE should resemble this patch, where there is only
simple single idle routine registration. If the full CPUIDLE is
picked at compile time (default for x86), we could have all the
features.
Sounds like a good option to try.
--Vaidy
next prev parent reply other threads:[~2010-10-20 20:04 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
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 [this message]
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=20101020200321.GC706@dirshya.in.ibm.com \
--to=svaidy@linux.vnet.ibm.com \
--cc=ak@linux.intel.com \
--cc=arjan@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=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.