Messages in this thread | | | Date | Tue, 03 Jun 2014 15:34:45 +0530 | From | "Srivatsa S. Bhat" <> | Subject | Re: [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
| |