Hi Amit,
Thanks for this input about performance improvement.
For the powersave_bias mode, it's normal that you have some
performances improvement because we run freq_lo_jiffies in low freq
and freq_high_jiffies in high freq with (freq_lo_jiffies +
freq_high_jiffies) = sample_rate whereas the duration was sample_rate
in low freq before.
you can also note that powersave_bias feature doesn't use the
sampling_down factor
Vincent
On 21 February 2011 10:38, Amit Kachhap <amit.kachhap@xxxxxxxxxx> wrote:
> Hi Vincent,
>
> I checked this patch and I can see some performance improvement in my
> arm platform also. So in your patch there are 2 changes. First one is
> for calculating delay after rate_mult is set, this can be tested with
> cpufreq-bench tool. For the second part which requires enabling power
> save bias , the cpufreq-bench does not do that. So I tested with one
> time setting of powersave_bias parameter and here also there is some
> increase in performance. But ideally powersave mode should have more
> power saving and some compromise in performance.
>
> //Amit Daniel
>
> On 15 February 2011 04:41, Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote:
>> Hi,
>>
>> The ondemand delay value is calculated before calling dbs_check_cpu
>> which can lead to a delay value of sampling_rate*sampling_down_factor
>> but a frequency set to the lowest value. The main result is a slow
>> responsiveness during this period. This patch moves the calculation of
>> delay after the call of dbs_check_cpu. I have seen this problem when
>> testing cpufreq-bench on my Arm platform.
>>
>> Vincent
>>
>> On 7 February 2011 17:14, Vincent Guittot <vincent.guittot@xxxxxxxxxx> wrote:
>>> calculate ondemand delay after dbs_check_cpu call because it can
>>> modify rate_mult value
>>>
>>> use freq_lo_jiffies value for the sub sample period of powersave_bias mode
>>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>
>>> ---
>>> drivers/cpufreq/cpufreq_ondemand.c | 20 +++++++++++++-------
>>> 1 files changed, 13 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/cpufreq_ondemand.c
>>> b/drivers/cpufreq/cpufreq_ondemand.c
>>> index 58aa85e..44c2dba 100644
>>> --- a/drivers/cpufreq/cpufreq_ondemand.c
>>> +++ b/drivers/cpufreq/cpufreq_ondemand.c
>>> @@ -641,13 +641,7 @@ static void do_dbs_timer(struct work_struct *work)
>>> container_of(work, struct cpu_dbs_info_s, work.work);
>>> unsigned int cpu = dbs_info->cpu;
>>> int sample_type = dbs_info->sample_type;
>>> -
>>> - /* We want all CPUs to do sampling nearly on same jiffy */
>>> - int delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
>>> - * dbs_info->rate_mult);
>>> -
>>> - if (num_online_cpus() > 1)
>>> - delay -= jiffies % delay;
>>> + int delay;
>>>
>>> mutex_lock(&dbs_info->timer_mutex);
>>>
>>> @@ -660,10 +654,22 @@ static void do_dbs_timer(struct work_struct *work)
>>> /* Setup timer for SUB_SAMPLE */
>>> dbs_info->sample_type = DBS_SUB_SAMPLE;
>>> delay = dbs_info->freq_hi_jiffies;
>>> + } else {
>>> + /* We want all CPUs to do sampling nearly on
>>> + * same jiffy
>>> + */
>>> + delay = usecs_to_jiffies(dbs_tuners_ins.sampling_rate
>>> + * dbs_info->rate_mult);
>>> +
>>> + if (num_online_cpus() > 1)
>>> + delay -= jiffies % delay;
>>> +
>>> }
>>> +
>>> } else {
>>> __cpufreq_driver_target(dbs_info->cur_policy,
>>> dbs_info->freq_lo, CPUFREQ_RELATION_H);
>>> + delay = dbs_info->freq_lo_jiffies;
>>> }
>>> schedule_delayed_work_on(cpu, &dbs_info->work, delay);
>>> mutex_unlock(&dbs_info->timer_mutex);
>>> --
>>> 1.7.1
>>>
>>
>> _______________________________________________
>> linaro-dev mailing list
>> linaro-dev@xxxxxxxxxxxxxxxx
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>>
>
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
