linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs
Date: Thu, 26 Feb 2015 10:06:15 +0100	[thread overview]
Message-ID: <54EEE207.7090006@linaro.org> (raw)
In-Reply-To: <alpine.LNX.2.02.1502251624570.11958@sbrk.org>

On 02/25/2015 04:56 PM, Sebastien Rannou wrote:
> Hi Daniel,
>
> Thanks for the explanation and thanks for the link, I wish I had read
> it beforehand.
>
> On Wed, 25 Feb 2015, Daniel Lezcano wrote:
>> If you have the possibility, I would suggest to apply the right methodology to
>> find the right values by using the description in the wiki page [1]. If you
>> can access to the energy values to enter / exit the state and the power
>> consumed in each idle state, then you can mathematically compute the right
>> values.
>
> Unfortunately I don't have access to the cost of transitions between
> states, nor do I have the time taken by each transition (which I could
> have used to infer the cost). I only have the power consumption of the
> different states.

If you have the consumption for the different idle state + running, you 
have 60% of the data :)

> I plan to find the adequate values by testing different combinations,
> but it is going to take some efforts before having a second
> patch.

You may waste your time because of the non deterministic prediction. 
Sometimes you will test with right values but wrong prediction and a 
cache 50% filled, sometimes you will test with wrong values and wrong 
prediction but a cache 20% filled etc ...

The only way to measure accurately is to identify the cpu power rails 
and measure the current peak when entering/exiting the different idle 
states with a device (oscilloscope, or whatever).

> Since this patch already improves the situation by using the
> vendor's values, I think it is a move in the right direction, even
> though not being the most adequate values.

Just to clarify, vendor's values are from an out-of-tree which means it 
does not exist from an opensource pov and hence does not enter in the 
equation to pick the patch or not.

Regarding the values you measured for perf and power, it appears we have 
a improvement in terms of performance but with a power consumption 
degradation.

I am not against this patch, but I would like to have the ack from 
another Armada maintainer (Jason, Andrew or Sebastian) to be sure this 
trade-off is accepted.

Thanks

   -- 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:[~2015-02-26  9:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-13 14:55 [PATCH] cpuidle: mvebu: update cpuidle thresholds for Armada XP SOCs s. rannou
2015-02-24 17:36 ` Gregory CLEMENT
2015-02-25 10:01 ` Daniel Lezcano
2015-02-25 15:56   ` Sebastien Rannou
2015-02-26  9:06     ` Daniel Lezcano [this message]
2015-03-10 18:05 ` Thomas Petazzoni
2015-03-10 18:35   ` Daniel Lezcano
2015-03-10 18:42     ` Andrew Lunn
2015-03-10 18:47     ` Gregory CLEMENT
2015-03-10 18:52       ` Daniel Lezcano
2015-03-13 10:33   ` 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=54EEE207.7090006@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).