lkml.org 
[lkml]   [2014]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads
On 06/03/2014 03:09 PM, Viresh Kumar wrote:
> On 3 June 2014 15:02, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
>> index e1c6433..3e8588f 100644
>> --- a/drivers/cpufreq/cpufreq_governor.c
>> +++ b/drivers/cpufreq/cpufreq_governor.c
>> @@ -36,14 +36,29 @@ void dbs_check_cpu(struct dbs_data *dbs_data, int cpu)
>> struct od_dbs_tuners *od_tuners = dbs_data->tuners;
>> struct cs_dbs_tuners *cs_tuners = dbs_data->tuners;
>> struct cpufreq_policy *policy;
>> + unsigned int sampling_rate;
>> unsigned int max_load = 0;
>> unsigned int ignore_nice;
>> unsigned int j;
>>
>> - if (dbs_data->cdata->governor == GOV_ONDEMAND)
>> + if (dbs_data->cdata->governor == GOV_ONDEMAND) {
>> + struct od_cpu_dbs_info_s *od_dbs_info;
>> +
>> + /*
>> + * Sometimes, the ondemand governor uses an additional
>> + * multiplier to give long delays. So apply this multiplier to
>> + * the 'sampling_rate', so as to keep the wake-up-from-idle
>> + * detection logic a bit conservative.
>> + */
>> + sampling_rate = od_tuners->sampling_rate;
>> + od_dbs_info = dbs_data->cdata->get_cpu_dbs_info_s(cpu);
>
> Probably do both above right after definition of od_dbs_info or merge
> above with it. and just keep below after the comment ?
>
>> + sampling_rate *= od_dbs_info->rate_mult;
>

Well, the method I used keeps the organization such that the code following
the comment does precisely what the comment says (i.e, get the sampling_rate,
fetch the multiplier, and then multiply). So I feel it makes it easier to
understand.

Regards,
Srivatsa S. Bhat



\
 
 \ /
  Last update: 2014-06-03 15:41    [W:0.087 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site