All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Len Brown <lenb@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Linux PM list <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	linaro-kernel@lists.linaro.org,
	Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH V2 4/5] cpuidle: menu: Fix the get_typical_interval
Date: Wed, 29 Oct 2014 19:15:34 +0100	[thread overview]
Message-ID: <54512EC6.4010901@linaro.org> (raw)
In-Reply-To: <CAJvTdKk=uQmon81Y8+jVmYggxg-K2sWC4vEFM+bycKCEAt0fFg@mail.gmail.com>

On 10/28/2014 03:48 AM, Len Brown wrote:
> On Thu, Oct 23, 2014 at 5:01 AM, Daniel Lezcano
> <daniel.lezcano@linaro.org> wrote:
>> The first time the 'get_typical_function' is called, it computes an average
>> of zero as no data is filled yet. That leads the 'data->predicted_us' variable
>> to be set to zero too.
>>
>> The caller, 'menu_select' will then do:
>>
>>          interactivity_req = data->predicted_us /
>>                          performance_multiplier(nr_iowaiters, cpu_load);
>>
>> That sets the interactivity_req to zero (0/performance...).
>>
>> and then
>>
>>          if (latency_req > interactivity_req)
>>                  latency_req = interactivity_req;
>>
>> ... setting 'latency_req' to zero too.
>>
>> No idle state will fulfill this constraint and we will go the C1 state as
>> default and leading to an update. So the next calls will compute an average
>> different from zero.
>>
>> Even if that works with the current code but with a broken semantic, it will
>> just break with the next patches where we are stricter with the latencies
>> check: the first check will fail (latency_req is zero), then no update will
>> occur leading to always falling to choose an idle state.
>>
>> As there are no previous values and it is pointless to compute a standard
>> deviation for these unexisting values. Just return without setting the
>> 'data->predicted_us' to zero.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>> ---
>>   drivers/cpuidle/governors/menu.c | 9 +++++++++
>>   1 file changed, 9 insertions(+)
>>
>> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
>> index 3907301..6ae8390 100644
>> --- a/drivers/cpuidle/governors/menu.c
>> +++ b/drivers/cpuidle/governors/menu.c
>> @@ -226,6 +226,15 @@ again:
>>          else
>>                  do_div(avg, divisor);
>>
>> +       /*
>> +        * We are at the very beginning and no data have been filled
>> +        * yet. Let's skip the standard deviation computation
>> +        * otherwise the data->predicted_us will be zero and that will
>> +        * lead to a zero latency req in the select function
>> +        */
>> +       if (!avg)
>> +               return;
>> +
>
> Unfortunately, you've touched ugly code,
> and your (correct) patch makes it ever-so slightly more ugly,
> instead of more clear.
>
> I think the code would read more clearly, and your patch would
> less obscure, if the code read something like this sow that it is
> clear at the menu_select level when and where we monkey
> with predicted_us:
>
> menu_select()...
> ...
> data->predicted_us = div_round64(bla bla bla
>
> interactivity_overrride_us = get_typical_interval(data);
>
> if (interactivity_override_us)
>    if (interactivity_predicted_us < data->predicted_us)
>          data->predicted_us = interactivity_override_us;
>
> And, of course, down inside get_typical_interval()
> ...
> if (!avg)
>          return 0;
> ...
> if (likely(stddev <= ULONG_MAX)) {
> ...
>          return avg;


Ok, thanks for the suggestion. I will look at reworking this patch.

   -- Daniel


-- 
  <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-10-29 18:15 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-23  9:01 [PATCH V2 1/5] sched: idle: cpuidle: Check the latency req before idle Daniel Lezcano
2014-10-23  9:01 ` [PATCH V2 2/5] sched: idle: Get the next timer event and pass it the cpuidle framework Daniel Lezcano
2014-10-23  9:01 ` [PATCH V2 3/5] cpuidle: idle: menu: Don't reflect when a state selection failed Daniel Lezcano
2014-10-28  2:01   ` Len Brown
2014-10-28 19:15     ` Daniel Lezcano
2014-10-28  7:01   ` Preeti Murthy
2014-10-28 18:28     ` Daniel Lezcano
2014-10-29  1:44       ` Preeti U Murthy
2014-10-29 16:54       ` Kevin Hilman
2014-10-29 16:54         ` Kevin Hilman
2014-10-29 21:11         ` Rafael J. Wysocki
2014-10-23  9:01 ` [PATCH V2 4/5] cpuidle: menu: Fix the get_typical_interval Daniel Lezcano
2014-10-23 16:43   ` Nicolas Pitre
2014-10-28  2:48   ` Len Brown
2014-10-29 18:15     ` Daniel Lezcano [this message]
2014-10-23  9:01 ` [PATCH V2 5/5] cpuidle: menu: Move the update function before its declaration Daniel Lezcano
2014-10-23 16:47   ` Nicolas Pitre
2014-10-28  2:53     ` Len Brown
2014-10-28  3:51 ` [PATCH V2 1/5] sched: idle: cpuidle: Check the latency req before idle Preeti Murthy
2014-10-28 18:59   ` Daniel Lezcano
2014-10-29  2:01     ` Preeti U Murthy
2014-11-05 14:28       ` Daniel Lezcano
2014-11-06  4:08         ` Preeti U Murthy
2014-11-06 12:27           ` Daniel Lezcano
2014-11-07  4:23             ` Preeti U Murthy
2014-11-06 13:42           ` Daniel Lezcano
2014-11-07  4:29             ` Preeti U Murthy
2014-11-07  9:35               ` Daniel Lezcano
2014-11-05 21:57 ` Rafael J. Wysocki
2014-11-05 21:41   ` 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=54512EC6.4010901@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=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.