All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.