linux-kernel - Re: [RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <53722094.5070805@semaphore.gr>
Date:	Tue, 13 May 2014 16:39:32 +0300
From:	Stratos Karafotis <stratosk@...aphore.gr>
To:	Yuyang Du <yuyang.du@...el.com>
CC:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Doug Smythies <dsmythies@...us.net>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Dirk Brandewie <dirk.j.brandewie@...el.com>,
	Dirk Brandewie <dirk.brandewie@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: [RFC PATCH] cpufreq: intel_pstate: Change the calculation of
 next pstate

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/