From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: rjw@rjwysocki.net, preeti@linux.vnet.ibm.com,
nicolas.pitre@linaro.org, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-kernel@lists.linaro.org,
patches@linaro.org, lenb@kernel.org
Subject: Re: [PATCH V3 2/6] sched: idle: cpuidle: Check the latency req before idle
Date: Mon, 10 Nov 2014 20:48:20 +0100 [thread overview]
Message-ID: <20141110194820.GD10501@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <5460F386.1050109@linaro.org>
On Mon, Nov 10, 2014 at 06:19:02PM +0100, Daniel Lezcano wrote:
> >I really don't get why the governors should know about this though, its
> >just another state, they should iterate all states and pick the best,
> >given the power usage this state should really never be eligible unless
> >we're QoS forced or whatnot.
>
> The governors just don't use the poll state at all, except for a couple of
> cases in menu.c defined above in the previous email. What is the rational of
> adding a state in the cpuidle driver and do everything we can to avoid using
> it ? From my POV, the poll state is a special state, we should remove from
> the driver's idle states like the arch_cpu_idle() is a specific idle state
> only used in idle.c (but which may overlap with an idle state in different
> archs eg. cpu_do_idle() and the 0th idle state).
So I disagree, I think poll-idle is an idle mode just like all the
others. It should be an available state to the governor and it should
treat it like any other.
I don't tihnk the whole ARCH_HAS_CPU_RELAX thing makes any kind of
sense, _every_ arch has some definition of it, the generic polling loop
is always a valid idle implementation.
What we can do is always populate the idle state table with it before
calling the regular drivers.
If the arch drivers have a 'better' latency_req==0 idle routine -- note
my argument on the ppc issue, I think its wrong -- it can replace the
existing one.
We should further remove all the special casing in the governors, its
always a valid state, but it should hardly ever be the most desirable
state.
I think the whole arch specific idle loop is a mistake, we already have
an (arch) interface into the idle routines, we don't need yet another.
next prev parent reply other threads:[~2014-11-10 19:48 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 14:31 [PATCH V3 0/6] sched: idle: cpuidle: cleanups and fixes Daniel Lezcano
2014-11-07 14:31 ` [PATCH V3 1/6] sched: idle: Add a weak arch_cpu_idle_poll function Daniel Lezcano
2014-11-08 10:39 ` Preeti U Murthy
2014-11-10 12:29 ` Peter Zijlstra
2014-11-10 14:20 ` Preeti U Murthy
2014-11-10 15:17 ` Peter Zijlstra
2014-11-11 11:00 ` Preeti U Murthy
2014-11-07 14:31 ` [PATCH V3 2/6] sched: idle: cpuidle: Check the latency req before idle Daniel Lezcano
2014-11-08 10:40 ` Preeti U Murthy
2014-11-10 12:41 ` Peter Zijlstra
2014-11-10 15:12 ` Daniel Lezcano
2014-11-10 15:28 ` Peter Zijlstra
2014-11-10 15:58 ` Daniel Lezcano
2014-11-10 16:15 ` Peter Zijlstra
2014-11-10 17:19 ` Daniel Lezcano
2014-11-10 19:48 ` Peter Zijlstra [this message]
2014-11-10 22:21 ` Daniel Lezcano
2014-11-11 10:20 ` Peter Zijlstra
2014-11-12 13:53 ` Daniel Lezcano
2014-11-12 15:02 ` Peter Zijlstra
2014-11-12 17:52 ` Daniel Lezcano
2014-11-07 14:31 ` [PATCH V3 3/6] sched: idle: Get the next timer event and pass it the cpuidle framework Daniel Lezcano
2014-11-08 10:44 ` Preeti U Murthy
2014-11-10 12:43 ` Peter Zijlstra
2014-11-10 15:15 ` Daniel Lezcano
2014-11-07 14:31 ` [PATCH V3 4/6] cpuidle: idle: menu: Don't reflect when a state selection failed Daniel Lezcano
2014-11-08 10:41 ` Preeti U Murthy
2014-11-07 14:31 ` [PATCH V3 5/6] cpuidle: menu: Fix the get_typical_interval Daniel Lezcano
2014-11-07 14:31 ` [PATCH V3 6/6] cpuidle: menu: Move the update function before its declaration Daniel Lezcano
2014-11-07 14:34 ` [PATCH V3 0/6] sched: idle: cpuidle: cleanups and fixes Daniel Lezcano
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=20141110194820.GD10501@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=daniel.lezcano@linaro.org \
--cc=lenb@kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=patches@linaro.org \
--cc=preeti@linux.vnet.ibm.com \
--cc=rjw@rjwysocki.net \
/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;
as well as URLs for NNTP newsgroup(s).