linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Preeti U Murthy <preeti@linux.vnet.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Arjan van de Ven <arjan@linux.intel.com>,
	Len Brown <len.brown@intel.com>
Cc: Preeti Murthy <preeti.lkml@gmail.com>,
	nicolas.pitre@linaro.org, mingo@redhat.com,
	Thomas Gleixner <tglx@linutronix.de>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	LKML <linux-kernel@vger.kernel.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Lists linaro-kernel <linaro-kernel@lists.linaro.org>
Subject: Re: [RFC PATCH 3/3] idle: store the idle state index in the struct rq
Date: Fri, 31 Jan 2014 15:04:32 +0100	[thread overview]
Message-ID: <52EBAD70.6040303@linaro.org> (raw)
In-Reply-To: <52EB6F65.8050008@linux.vnet.ibm.com>

On 01/31/2014 10:39 AM, Preeti U Murthy wrote:
> Hi Peter,
>
> On 01/31/2014 02:32 PM, Peter Zijlstra wrote:
>> On Fri, Jan 31, 2014 at 02:15:47PM +0530, Preeti Murthy wrote:
>>>>
>>>> If the driver does its own random mapping that will break the governor
>>>> logic. So yes, the states are ordered, the higher the index is, the more you
>>>> save power and the higher the exit latency is.
>>>
>>> The above point holds true for only the ladder governor which sees the idle
>>> states indexed in the increasing order of target_residency/exit_latency.
>>>
>>> However this is not true as far as I can see in the menu governor. It
>>> acknowledges the dynamic ordering of idle states as can be seen in the
>>> menu_select() function in the menu governor, where the idle state for the
>>> CPU gets chosen.  You will notice that, even if it is found that the predicted
>>> idle time of the CPU is smaller than the target residency of an idle state,
>>> the governor continues to search for suitable idle states in the higher indexed
>>> states although it should have halted if the idle states' were ordered according
>>> to their target residency.. The same holds for exit_latency.
>>>
>>> Hence I think this patch would make sense only with additional information
>>> like exit_latency or target_residency is present for the scheduler. The idle
>>> state index alone will not be sufficient.
>>
>> Alternatively, can we enforce sanity on the cpuidle infrastructure to
>> make the index naturally ordered? If not, please explain why :-)
>
> The commit id 71abbbf856a0e70 says that there are SOCs which could have
> their target_residency and exit_latency values change at runtime. This
> commit thus removed the ordering of the idle states according to their
> target_residency/exit_latency. Adding Len and Arjan to the CC.

This commit is outdated, AFAICT.

Indeed, there are dynamic idle states. Some idle states are added or 
removed when a laptop is going to battery or plugged in.

In ACPI, the power event leads the acpi cpuidle driver to disable the 
cpuidle framework, get the idle states which are ordered, and re-enable 
the cpuidle framework which in turn kicks all the cpus. So the index in 
the struct rq should be always ok.




-- 
  <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

  parent reply	other threads:[~2014-01-31 14:04 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-30 14:09 [RFC PATCH 0/3] cpuidle/sched: move main idle function in the idle.c Daniel Lezcano
2014-01-30 14:09 ` [RFC PATCH 1/3] cpuidle: split cpuidle_idle_call main function into functions Daniel Lezcano
2014-01-30 15:27   ` Peter Zijlstra
2014-01-30 15:39     ` Daniel Lezcano
2014-01-30 19:39   ` Nicolas Pitre
2014-01-31 14:10     ` Daniel Lezcano
2014-01-30 14:09 ` [RFC PATCH 2/3] cpuidle: move the cpuidle_idle_call function to idle.c Daniel Lezcano
2014-01-30 19:42   ` Nicolas Pitre
2014-01-30 14:09 ` [RFC PATCH 3/3] idle: store the idle state index in the struct rq Daniel Lezcano
2014-01-30 15:31   ` Peter Zijlstra
2014-01-30 16:27     ` Daniel Lezcano
2014-01-30 16:35       ` Peter Zijlstra
2014-01-30 17:25         ` Daniel Lezcano
2014-01-30 17:50           ` Lorenzo Pieralisi
2014-01-30 21:02             ` Nicolas Pitre
2014-01-31  9:46               ` Vincent Guittot
2014-01-31 10:04               ` Lorenzo Pieralisi
2014-01-31 10:44               ` Daniel Lezcano
2014-01-31  8:45           ` Preeti Murthy
2014-01-31  9:02             ` Peter Zijlstra
2014-01-31  9:39               ` Preeti U Murthy
2014-01-31 10:24                 ` Peter Zijlstra
2014-01-31 14:04                 ` Daniel Lezcano [this message]
2014-01-31 14:12                   ` Dietmar Eggemann
2014-01-31 15:07                 ` Arjan van de Ven
2014-01-31 15:37                   ` Daniel Lezcano
2014-01-31 15:50                     ` Arjan van de Ven
2014-01-31 16:35                       ` Daniel Lezcano
2014-01-31 16:42                         ` Arjan van de Ven
2014-01-31 18:19                       ` Nicolas Pitre
2014-02-01  6:00                         ` Brown, Len
2014-02-01 15:31                           ` Nicolas Pitre
2014-02-01 19:39                             ` Brown, Len
2014-02-01 20:13                               ` Nicolas Pitre
2014-02-01 15:40                           ` Lorenzo Pieralisi
2014-02-03 12:54                         ` Morten Rasmussen
2014-02-03 14:38                           ` Arjan van de Ven
2014-02-03 14:56                             ` Peter Zijlstra
2014-02-03 16:17                               ` Arjan van de Ven
2014-02-11 16:41                                 ` Peter Zijlstra
2014-02-11 17:12                                   ` Arjan van de Ven
2014-02-11 19:47                                     ` Peter Zijlstra
2014-02-12 15:16                                 ` Lorenzo Pieralisi
2014-02-12 16:14                                   ` Arjan van de Ven
2014-02-12 17:37                                     ` Lorenzo Pieralisi
2014-02-12 19:05                                       ` Nicolas Pitre
2014-02-04  9:14                               ` Ingo Molnar
2014-02-04 14:53                                 ` Arjan van de Ven
2014-02-04 14:56                                 ` Arjan van de Ven
2014-02-03 14:58                           ` Nicolas Pitre
2014-01-31 10:15             ` Daniel Lezcano
2014-02-03  6:33               ` Preeti U Murthy

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=52EBAD70.6040303@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=arjan@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=peterz@infradead.org \
    --cc=preeti.lkml@gmail.com \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    /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).