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

2014-05-17 Thread Stratos Karafotis
Hi all! On 12/05/2014 11:30 μμ, Stratos Karafotis wrote: > On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: >> Hi Dirk, >> >> On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: >>> On 05/05/2014 04:57 PM, Stratos Karafotis wrote: Currently the driver calculates the next pstate proportional to

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

2014-05-17 Thread Stratos Karafotis
Hi all! On 12/05/2014 11:30 μμ, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Hi Dirk, On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: On 05/05/2014 04:57 PM, Stratos Karafotis wrote: Currently the driver calculates the next pstate proportional to core_busy

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

2014-05-13 Thread Stratos Karafotis
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. >>>

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

2014-05-13 Thread Yuyang Du
> > > 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,

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

2014-05-13 Thread Yuyang Du
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

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

2014-05-13 Thread Stratos Karafotis
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

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

2014-05-12 Thread Yuyang Du
On Tue, May 13, 2014 at 07:16:24AM +0300, Stratos Karafotis wrote: > On 12/05/2014 11:01 μμ, Yuyang Du wrote: > > On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: > >> Hi, > >> > >> On 12/05/2014 10:34 μμ, Yuyang Du wrote: > >>> On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos

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

2014-05-12 Thread Stratos Karafotis
On 12/05/2014 11:01 μμ, Yuyang Du wrote: > On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: >> Hi, >> >> On 12/05/2014 10:34 μμ, Yuyang Du wrote: >>> On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote:

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

2014-05-12 Thread Yuyang Du
On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: > Hi, > > On 12/05/2014 10:34 μμ, Yuyang Du wrote: > > On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: > >> On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: > >> > >> Next performance state = min_perf +

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

2014-05-12 Thread Stratos Karafotis
Hi, On 12/05/2014 10:34 μμ, Yuyang Du wrote: > On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: >> On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: >> >> Next performance state = min_perf + (max_perf - min_perf) * load / 100 >> > Hi, > > This formula is fundamentally broken.

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

2014-05-12 Thread Yuyang Du
On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: > On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: > > Next performance state = min_perf + (max_perf - min_perf) * load / 100 > Hi, This formula is fundamentally broken. You need to associate the load with its frequency. Thanks,

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

2014-05-12 Thread Stratos Karafotis
On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: > Hi Dirk, > > On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: >> On 05/05/2014 04:57 PM, Stratos Karafotis wrote: >>> Currently the driver calculates the next pstate proportional to >>> core_busy factor, scaled by the ratio max_pstate /

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

2014-05-12 Thread Stratos Karafotis
On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Hi Dirk, On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: On 05/05/2014 04:57 PM, Stratos Karafotis wrote: Currently the driver calculates the next pstate proportional to core_busy factor, scaled by the ratio max_pstate / current_pstate. Using

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

2014-05-12 Thread Yuyang Du
On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Next performance state = min_perf + (max_perf - min_perf) * load / 100 Hi, This formula is fundamentally broken. You need to associate the load with its frequency. Thanks,

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

2014-05-12 Thread Stratos Karafotis
Hi, On 12/05/2014 10:34 μμ, Yuyang Du wrote: On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Next performance state = min_perf + (max_perf - min_perf) * load / 100 Hi, This formula is fundamentally broken. You need to

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

2014-05-12 Thread Yuyang Du
On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: Hi, On 12/05/2014 10:34 μμ, Yuyang Du wrote: On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Next performance state = min_perf + (max_perf - min_perf)

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

2014-05-12 Thread Stratos Karafotis
On 12/05/2014 11:01 μμ, Yuyang Du wrote: On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: Hi, On 12/05/2014 10:34 μμ, Yuyang Du wrote: On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote: On 09/05/2014 05:56 μμ, Stratos Karafotis wrote: Next performance

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

2014-05-12 Thread Yuyang Du
On Tue, May 13, 2014 at 07:16:24AM +0300, Stratos Karafotis wrote: On 12/05/2014 11:01 μμ, Yuyang Du wrote: On Tue, May 13, 2014 at 06:59:42AM +0300, Stratos Karafotis wrote: Hi, On 12/05/2014 10:34 μμ, Yuyang Du wrote: On Mon, May 12, 2014 at 11:30:03PM +0300, Stratos Karafotis wrote:

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

2014-05-09 Thread Stratos Karafotis
Hi Dirk, On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: > On 05/05/2014 04:57 PM, Stratos Karafotis wrote: >> Currently the driver calculates the next pstate proportional to >> core_busy factor, scaled by the ratio max_pstate / current_pstate. >> >> Using the scaled load (core_busy) to calculate

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

2014-05-09 Thread Stratos Karafotis
Hi Dirk, On 08/05/2014 11:52 μμ, Dirk Brandewie wrote: On 05/05/2014 04:57 PM, Stratos Karafotis wrote: Currently the driver calculates the next pstate proportional to core_busy factor, scaled by the ratio max_pstate / current_pstate. Using the scaled load (core_busy) to calculate the next

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

2014-05-08 Thread Dirk Brandewie
On 05/05/2014 04:57 PM, Stratos Karafotis wrote: > Currently the driver calculates the next pstate proportional to > core_busy factor, scaled by the ratio max_pstate / current_pstate. > > Using the scaled load (core_busy) to calculate the next pstate > is not always correct, because there are

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

2014-05-08 Thread Dirk Brandewie
On 05/05/2014 04:57 PM, Stratos Karafotis wrote: Currently the driver calculates the next pstate proportional to core_busy factor, scaled by the ratio max_pstate / current_pstate. Using the scaled load (core_busy) to calculate the next pstate is not always correct, because there are cases

[RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate

2014-05-05 Thread Stratos Karafotis
Currently the driver calculates the next pstate proportional to core_busy factor, scaled by the ratio max_pstate / current_pstate. Using the scaled load (core_busy) to calculate the next pstate is not always correct, because there are cases that the load is independent from current pstate. For

[RFC PATCH] cpufreq: intel_pstate: Change the calculation of next pstate

2014-05-05 Thread Stratos Karafotis
Currently the driver calculates the next pstate proportional to core_busy factor, scaled by the ratio max_pstate / current_pstate. Using the scaled load (core_busy) to calculate the next pstate is not always correct, because there are cases that the load is independent from current pstate. For