From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Peter Zijlstra <peterz@infradead.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 23:21:19 +0100 [thread overview]
Message-ID: <54613A5F.7060107@linaro.org> (raw)
In-Reply-To: <20141110194820.GD10501@worktop.programming.kicks-ass.net>
On 11/10/2014 08:48 PM, Peter Zijlstra wrote:
> 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.
The governors are just ignoring it, except for a small timer
optimization in menu.c (and I am still not convinced it is worth to have
it). I don't see the point to add a state we don't want to use.
Eg. on my server it was called 2 times over 1313856 times.
> 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.
I am not sure to understand. You want to add the poll idle loop in all
the drivers ?
What about "safe_halt()" ? (arch_cpu_idle() for x86). It is also an idle
state. Why not add it in the idle state table also ?
> 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.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2014-11-10 22:21 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
2014-11-10 22:21 ` Daniel Lezcano [this message]
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=54613A5F.7060107@linaro.org \
--to=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=peterz@infradead.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 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.