On 02/05/2014 03:26 μμ, Rafael J. Wysocki wrote:
> On Thursday, May 01, 2014 06:48:08 PM Dirk Brandewie wrote:
>> On 05/01/2014 04:18 PM, Rafael J. Wysocki wrote:
>>> On Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
On 05/01/2014 02:00 PM, Stratos Karafotis wrote:
> Currently th
On Thursday, May 01, 2014 06:48:08 PM Dirk Brandewie wrote:
> On 05/01/2014 04:18 PM, Rafael J. Wysocki wrote:
> > On Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
> >> On 05/01/2014 02:00 PM, Stratos Karafotis wrote:
> >>> Currently the driver calculates the next pstate proportional to
On 05/01/2014 04:18 PM, Rafael J. Wysocki wrote:
On Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
On 05/01/2014 02:00 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 Thursday, May 01, 2014 02:30:42 PM Dirk Brandewie wrote:
> On 05/01/2014 02:00 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 calc
On 05/01/2014 02:00 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 that t
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 ex
6 matches
Mail list logo