On 06/03/2013 02:24 PM, Viresh Kumar wrote:
> On 3 June 2013 16:27, Rafael J. Wysocki wrote:
>> The question is if we want policy->max to re-scale them effectively (i.e. to
>> change weights so that the maximum load maps to the highest frequency
>> available
>> at the moment) or if we want
On 3 June 2013 16:27, Rafael J. Wysocki wrote:
> The question is if we want policy->max to re-scale them effectively (i.e. to
> change weights so that the maximum load maps to the highest frequency
> available
> at the moment) or if we want policy->max to work as a cap (i.e. to map all
> loads
On Monday, June 03, 2013 12:25:02 PM Viresh Kumar wrote:
> Sent half written mail.. sorry.. will continue from where I left.
>
> On 3 June 2013 12:21, Viresh Kumar wrote:
>
> > So, obviously the calculations aren't the same..
>
> Now, this is how I understood these two different variables:
> -
On Monday, June 03, 2013 12:21:47 PM Viresh Kumar wrote:
> On 2 June 2013 01:07, Rafael J. Wysocki wrote:
> > On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
>
> >> Even removal of __cpufreq_driver_getavg() should be done in a separate
> >> patch, so that it can be reverted easily if
Sent half written mail.. sorry.. will continue from where I left.
On 3 June 2013 12:21, Viresh Kumar wrote:
> So, obviously the calculations aren't the same..
Now, this is how I understood these two different variables:
- cpuinfo.max_freq: maximum frequency (in kHz) which is
supported by this
On 2 June 2013 01:07, Rafael J. Wysocki wrote:
> On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
>> Even removal of __cpufreq_driver_getavg() should be done in a separate
>> patch, so that it can be reverted easily if required later.
>
> Why would you want to revert it separately?
We
On 1 June 2013 21:36, Stratos Karafotis wrote:
> On 06/01/2013 05:56 PM, Viresh Kumar wrote:
>> Even removal of __cpufreq_driver_getavg() should be done in a separate
>> patch, so that it can be reverted easily if required later.
>
> Thanks, Viresh. I will do the removal of that function in a
On 1 June 2013 21:36, Stratos Karafotis strat...@semaphore.gr wrote:
On 06/01/2013 05:56 PM, Viresh Kumar wrote:
Even removal of __cpufreq_driver_getavg() should be done in a separate
patch, so that it can be reverted easily if required later.
Thanks, Viresh. I will do the removal of that
On 2 June 2013 01:07, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
Even removal of __cpufreq_driver_getavg() should be done in a separate
patch, so that it can be reverted easily if required later.
Why would you want to revert it
Sent half written mail.. sorry.. will continue from where I left.
On 3 June 2013 12:21, Viresh Kumar viresh.ku...@linaro.org wrote:
So, obviously the calculations aren't the same..
Now, this is how I understood these two different variables:
- cpuinfo.max_freq: maximum frequency (in kHz) which
On Monday, June 03, 2013 12:21:47 PM Viresh Kumar wrote:
On 2 June 2013 01:07, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
Even removal of __cpufreq_driver_getavg() should be done in a separate
patch, so that it can be reverted easily
On Monday, June 03, 2013 12:25:02 PM Viresh Kumar wrote:
Sent half written mail.. sorry.. will continue from where I left.
On 3 June 2013 12:21, Viresh Kumar viresh.ku...@linaro.org wrote:
So, obviously the calculations aren't the same..
Now, this is how I understood these two different
On 3 June 2013 16:27, Rafael J. Wysocki r...@sisk.pl wrote:
The question is if we want policy-max to re-scale them effectively (i.e. to
change weights so that the maximum load maps to the highest frequency
available
at the moment) or if we want policy-max to work as a cap (i.e. to map all
On 06/03/2013 02:24 PM, Viresh Kumar wrote:
On 3 June 2013 16:27, Rafael J. Wysocki r...@sisk.pl wrote:
The question is if we want policy-max to re-scale them effectively (i.e. to
change weights so that the maximum load maps to the highest frequency
available
at the moment) or if we want
On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
> On 31 May 2013 22:03, Stratos Karafotis wrote:
> > On 05/31/2013 11:51 AM, Viresh Kumar wrote:
> >> I believe you should have removed other users of getavg() in a separate
> >> patch and also cc'd relevant people so that you can some
On 06/01/2013 05:56 PM, Viresh Kumar wrote:
> On 31 May 2013 22:03, Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>>> I believe you should have removed other users of getavg() in a separate
>>> patch and also cc'd relevant people so that you can some review comments
>>>
On 31 May 2013 22:03, Stratos Karafotis wrote:
> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>> I believe you should have removed other users of getavg() in a separate
>> patch and also cc'd relevant people so that you can some review comments
>> from them.
>
> I will split the patch in two. If
On 06/01/2013 03:27 PM, Rafael J. Wysocki wrote:
> On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
>> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
> On 05/31/2013 11:51 AM, Viresh Kumar wrote:
> >> ---
> >> arch/x86/include/asm/processor.h | 29 --
> >> drivers/cpufreq/Makefile | 2 +-
> >> drivers/cpufreq/acpi-cpufreq.c | 5
> >>
On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 5
On 06/01/2013 03:27 PM, Rafael J. Wysocki wrote:
On Friday, May 31, 2013 07:33:06 PM Stratos Karafotis wrote:
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
On 31 May 2013 22:03, Stratos Karafotis strat...@semaphore.gr wrote:
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
I believe you should have removed other users of getavg() in a separate
patch and also cc'd relevant people so that you can some review comments
from them.
I will split the patch
On 06/01/2013 05:56 PM, Viresh Kumar wrote:
On 31 May 2013 22:03, Stratos Karafotis strat...@semaphore.gr wrote:
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
I believe you should have removed other users of getavg() in a separate
patch and also cc'd relevant people so that you can some review
On Saturday, June 01, 2013 08:26:47 PM Viresh Kumar wrote:
On 31 May 2013 22:03, Stratos Karafotis strat...@semaphore.gr wrote:
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
I believe you should have removed other users of getavg() in a separate
patch and also cc'd relevant people so that you
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
>> ---
>> arch/x86/include/asm/processor.h | 29 --
>> drivers/cpufreq/Makefile | 2 +-
>> drivers/cpufreq/acpi-cpufreq.c | 5
>> drivers/cpufreq/cpufreq.c | 21
>>
On Friday, May 31, 2013 02:24:59 PM Viresh Kumar wrote:
> On 31 May 2013 02:37, Stratos Karafotis wrote:
>
> Ahh.. earlier mail got sent without me doing complete review :(
>
> > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> > +static void od_check_cpu(int cpu, unsigned
On 31 May 2013 02:37, Stratos Karafotis wrote:
Ahh.. earlier mail got sent without me doing complete review :(
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> +static void od_check_cpu(int cpu, unsigned int load)
> {
> struct od_cpu_dbs_info_s *dbs_info =
Sorry for joining the party so late.. I was running away from reviewing it :(
On 31 May 2013 02:37, Stratos Karafotis wrote:
> Ondemand calculates load in terms of frequency and increases it only
> if the load_freq is greater than up_threshold multiplied by current
> or average frequency. This
Sorry for joining the party so late.. I was running away from reviewing it :(
On 31 May 2013 02:37, Stratos Karafotis strat...@semaphore.gr wrote:
Ondemand calculates load in terms of frequency and increases it only
if the load_freq is greater than up_threshold multiplied by current
or average
On 31 May 2013 02:37, Stratos Karafotis strat...@semaphore.gr wrote:
Ahh.. earlier mail got sent without me doing complete review :(
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
+static void od_check_cpu(int cpu, unsigned int load)
{
struct od_cpu_dbs_info_s
On Friday, May 31, 2013 02:24:59 PM Viresh Kumar wrote:
On 31 May 2013 02:37, Stratos Karafotis strat...@semaphore.gr wrote:
Ahh.. earlier mail got sent without me doing complete review :(
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
+static void od_check_cpu(int
On 05/31/2013 11:51 AM, Viresh Kumar wrote:
---
arch/x86/include/asm/processor.h | 29 --
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/acpi-cpufreq.c | 5
drivers/cpufreq/cpufreq.c | 21
Ondemand calculates load in terms of frequency and increases it only
if the load_freq is greater than up_threshold multiplied by current
or average frequency. This seems to produce oscillations of frequency
between min and max because, for example, a relatively small load can
easily saturate
Ondemand calculates load in terms of frequency and increases it only
if the load_freq is greater than up_threshold multiplied by current
or average frequency. This seems to produce oscillations of frequency
between min and max because, for example, a relatively small load can
easily saturate
34 matches
Mail list logo
