All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stratos Karafotis <stratosk@semaphore.gr>
To: Yuyang Du <yuyang.du@intel.com>
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 16:39:32 +0300	[thread overview]
Message-ID: <53722094.5070805@semaphore.gr> (raw)
In-Reply-To: <20140512215956.GC10676@intel.com>

On 13/05/2014 12:59 πμ, Yuyang Du wrote:
>>>> 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
> 

[I rewrite my last post, because I think something happened with my email server
and the message haven't delivered properly]

I mean that if a CPU was busy 100% at 100MHz it would be most probably (or we
should consider that would be) busy 100% at 1000MHz.

We don't know the amount of load in next sampling period. We also
don't know the type of load. A mathematical calculation that started in
previous sampling period and kept the CPU 100% busy, will most probably
keep the CPU also 100% busy in the next sampling period.

Scaling the load will be wrong in this case.

Of course, I don't say that the "amount" of load in these 2 periods are the same.

If @1000Mhz the load drops to 10%, the proposed method will select as target freq
190MHz.


Stratos

  reply	other threads:[~2014-05-13 13:39 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 ` [RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate Yuyang Du
2014-05-13 13:39   ` Stratos Karafotis [this message]
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=53722094.5070805@semaphore.gr \
    --to=stratosk@semaphore.gr \
    --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=viresh.kumar@linaro.org \
    --cc=yuyang.du@intel.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 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.