From: Yuyang Du <yuyang.du@intel.com>
To: Stratos Karafotis <stratosk@semaphore.gr>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Doug Smythies <dsmythies@telus.net>,
" linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Dirk Brandewie <dirk.j.brandewie@intel.com>,
Dirk Brandewie <dirk.brandewie@gmail.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate
Date: Tue, 13 May 2014 05:59:56 +0800 [thread overview]
Message-ID: <20140512215956.GC10676@intel.com> (raw)
In-Reply-To: <bf3034d0-5c89-4ddb-921a-a92a4aed39f8@fmsmsx105.amr.corp.intel.com>
> > > Maybe, in some cases yes. But not always.
> > > For example, please consider a CPU running a tight "for" loop in 100MHz
> > > for a couple of seconds. This produces a load of 100%.
> > > It will produce the same load (100%) in any other frequency.
> >
> > Still fundamentally wrong, because you are not making a fair
> > comparison ("load" in 100MHz vs. any other freq).
> >
>
> I'm sorry, I didn't understand you. What do you mean it's not fair?
>
> In the above example (considering a CPU with min freq 100MHz and max freq 1000Mhz) a load of 100% should also be 100 in other next frequency.
>
> If we scale the load we will calculate the load in 100Mhz to 10%. I believe that this is not true.
The amount of work @100MHz is the same as the amount of work @1000MHZ, in your
example? Put another way, your proposed method does not do any extra better,
but do worse in other cases (what if @1000MHz, the load drops to 10%).
That said, your case cannot be used against associating freq with load. That also
said, by associating freq with load, we will finally get highest freq as well
(in your case).
Yuyang
next parent reply other threads:[~2014-05-13 6:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bf3034d0-5c89-4ddb-921a-a92a4aed39f8@fmsmsx105.amr.corp.intel.com>
2014-05-12 21:59 ` Yuyang Du [this message]
2014-05-13 13:39 ` [RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate Stratos Karafotis
2014-05-05 23:57 Stratos Karafotis
2014-05-08 20:52 ` Dirk Brandewie
2014-05-09 14:56 ` Stratos Karafotis
2014-05-12 20:30 ` Stratos Karafotis
2014-05-12 19:34 ` Yuyang Du
2014-05-13 3:59 ` Stratos Karafotis
2014-05-12 20:01 ` Yuyang Du
2014-05-13 4:16 ` Stratos Karafotis
2014-05-12 20:34 ` Yuyang Du
2014-05-17 6:52 ` Stratos Karafotis
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=20140512215956.GC10676@intel.com \
--to=yuyang.du@intel.com \
--cc=dirk.brandewie@gmail.com \
--cc=dirk.j.brandewie@intel.com \
--cc=dsmythies@telus.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=stratosk@semaphore.gr \
--cc=viresh.kumar@linaro.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).