linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Ai Li" <aili@codeaurora.org>
To: 'Arjan van de Ven' <arjan@linux.intel.com>
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 13:19:43 -0600	[thread overview]
Message-ID: <000301cb251b$d8cb7bf0$8a6273d0$@org> (raw)
In-Reply-To: <4C4096A8.8060306@linux.intel.com>

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


> > One of the concerns I have is backwards compatibility.  As far as
> I
> > know, none of the current cpuidle drivers use the power_usage
> field.
> > If we always do compare_power, those drivers would break until
> > someone with technical device knowledge update the drivers to
> specify
> > power...  I could derive fake power_usage numbers by default,
> using
> > the cstate index position.  That seems kind of hacky but it would
> > remove the need for the compare_power flag and retain the current
> > behavior when cpuidle drivers do not provide their own power
> numbers.
> >
> 
> I'm fine with this approach actually; if someone does not fill it
> in, we fake data that makes it
> valid... better than getting complex code.

OK.

~Ai

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum



  reply	other threads:[~2010-07-16 19:19 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 [this message]
2010-07-16 19:33         ` Arjan van de Ven
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='000301cb251b$d8cb7bf0$8a6273d0$@org' \
    --to=aili@codeaurora.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@linux.intel.com \
    --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).