linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arjan van de Ven <arjan@linux.intel.com>
To: Ai Li <aili@codeaurora.org>
Cc: akpm@linux-foundation.org, dwalker@codeaurora.org, mingo@elte.hu,
	shemminger@vyatta.com, czoccolo@gmail.com, len.brown@intel.com,
	linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-pm@lists.linux-foundation.org
Subject: Re: [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamic states
Date: Fri, 16 Jul 2010 12:33:10 -0700	[thread overview]
Message-ID: <4C40B3F6.5010106@linux.intel.com> (raw)
In-Reply-To: <000301cb251b$d8cb7bf0$8a6273d0$@org>

On 7/16/2010 12:19 PM, Ai Li wrote:
>> the power value in the structure should represent ONLY the power
>> level during the low power stage.
>> And this should be independent of total duration.
>> all other power is taken into account in terms of break even
>> point/etc...
>>      
> With static cstates, determining the break even point is
> straitforward, compare the power numbers of state Cn and Cn-1, since
> the states are ordered in increasing order of latency and power.
> With dynamic cstates, Cn-1 may not be a valid state to compare any
> more, for example, because Cn-1's latency may have become too high.
> It seems the driver would need to know which cstate the govenor would
> compare Cn to, and that would break the design philosophy of driver +
> govenor.  The break even point does not seem to have a transistive
> property, where the govenor can calculat Cn vs Cn-2 from some
> arithmatic combination of Cn vs Cn-1 and Cn-1 vs Cn-2 values.  On the
> other hand, if the power_usage field also includes the entry and exit
> stages, then the driver does not need to know whether it should
> calculate break even point for Cn vs Cn-1, or Cn vs Cn-2, etc.
>    

that's nice in theory.
in practice though, this is all noise compared to some of the accuracy 
in the predictions.

break even generally is done against C1 only (since C1 is assumed to 
always be there)....
yes it'd be nice to also have it against Cx in a matrix form, but that 
is a level of complexity that
hasn't been worth it.

Note that the prediction is.... a prediction. I can show you data on how 
well it does (now that it's
much better in 2.6.35-rc), but it's still "50% of the time we're within 
a factor of two of actual".
not "we're 90% of the time within 10%".


  reply	other threads:[~2010-07-16 19:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-15 20:30 [PATCH] cpuidle: extend cpuidle and menu governor to handle dynamic states Ai Li
2010-07-16  4:07 ` Arjan van de Ven
2010-07-16 17:25   ` Ai Li
2010-07-16 17:28     ` Arjan van de Ven
2010-07-16 19:19       ` Ai Li
2010-07-16 19:33         ` Arjan van de Ven [this message]
2010-07-16 19:52           ` Ai Li

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=4C40B3F6.5010106@linux.intel.com \
    --to=arjan@linux.intel.com \
    --cc=aili@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=czoccolo@gmail.com \
    --cc=dwalker@codeaurora.org \
    --cc=len.brown@intel.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mingo@elte.hu \
    --cc=shemminger@vyatta.com \
    /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).