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
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
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.
>>>
> > > 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,
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
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
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
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:
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 +
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.
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,
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 /
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
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,
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
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)
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
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:
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
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
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
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
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
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
On 04/29/2014 02:52 PM, Rafael J. Wysocki wrote:
On Tuesday, April 29, 2014 07:34:46 PM Stratos Karafotis wrote:
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis wrote:
Currently the driver calculates the next pstate proportional to
core_busy
On 04/29/2014 02:52 PM, Rafael J. Wysocki wrote:
On Tuesday, April 29, 2014 07:34:46 PM Stratos Karafotis wrote:
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis strat...@semaphore.gr wrote:
Currently the driver calculates the next pstate
On Tuesday, April 29, 2014 07:34:46 PM Stratos Karafotis wrote:
> On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
> > Cc'd Dirk,
> >
> > On 28 April 2014 03:42, Stratos Karafotis wrote:
> >> Currently the driver calculates the next pstate proportional to
> >> core_busy factor and reverse
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
> Cc'd Dirk,
>
> On 28 April 2014 03:42, Stratos Karafotis wrote:
>> Currently the driver calculates the next pstate proportional to
>> core_busy factor and reverse proportional to current pstate.
>>
>> Change the above method and calculate the next
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis strat...@semaphore.gr wrote:
Currently the driver calculates the next pstate proportional to
core_busy factor and reverse proportional to current pstate.
Change the above method and calculate
On Tuesday, April 29, 2014 07:34:46 PM Stratos Karafotis wrote:
On 29/04/2014 07:58 πμ, Viresh Kumar wrote:
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis strat...@semaphore.gr wrote:
Currently the driver calculates the next pstate proportional to
core_busy factor and reverse
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis wrote:
> Currently the driver calculates the next pstate proportional to
> core_busy factor and reverse proportional to current pstate.
>
> Change the above method and calculate the next pstate independently
> of current pstate.
We must
Cc'd Dirk,
On 28 April 2014 03:42, Stratos Karafotis strat...@semaphore.gr wrote:
Currently the driver calculates the next pstate proportional to
core_busy factor and reverse proportional to current pstate.
Change the above method and calculate the next pstate independently
of current
Currently the driver calculates the next pstate proportional to
core_busy factor and reverse proportional to current pstate.
Change the above method and calculate the next pstate independently
of current pstate.
Tested on Intel i7-3770 CPU @ 3.40GHz.
Phoronix benchmark of Linux Kernel
Currently the driver calculates the next pstate proportional to
core_busy factor and reverse proportional to current pstate.
Change the above method and calculate the next pstate independently
of current pstate.
Tested on Intel i7-3770 CPU @ 3.40GHz.
Phoronix benchmark of Linux Kernel
34 matches
Mail list logo
