Hi Viresh,
> On 24 May 2013 14:00, Lukasz Majewski <l.majewski@xxxxxxxxxxx> wrote:
> > The overclock frequency (1.5 GHz) is possible to set as an ordinary,
> > available frequency (policy->max) for ondemand.
> >
> > Unfortunately with our load patterns, this frequency rapidly
> > increases internal chip temperature (chip goes out of available
> > power/thermal dissipation range), and consumes extra power when not
> > needed.
> >
> > The core idea with overclock is to increase ("boost") the frequency
> > when conditions allow to do it (for example load is affined to a
> > single core, other are idle). Then we will not exceed power/thermal
> > budget, but increase performance (and even save power).
> >
> >
> > Overclocking is efficiently utilized by LAB, which relies on a
> > number of idle cpus. Thus, we can easily asses if we can enable it.
> >
> > I also foresee potential use of overclocking, when scheduler will
> > take a major role of power saver for mobile (ARM) linux. Since it
> > will try to pack as much tasks as possible to a single core - it
> > will need a framework/API to "boost" their execution.
>
> Okay.. so its exactly what I thought the reason would be.
>
> What I would have done if I was in your place is:
>
> Add following sysfs tunables to ondemand governor:
>
> - overdrive_freq: We will go over this frequency only when
> number of busy cores is <= overdrive_cores..
> For your case it will be 1.4 GHz
>
> - overdrive_cores: We will enable overdrive frequencies only if no. of
> busy cores is <= overdrive_cores. Zero by default (So, that this
> feature is disabled by default) and 1 for your case.
>
> And your driver will include all the available frequencies in the freq
> table.
This is not safe IMHO to add permanently overclocked frequency to the
freq table. Since, for example, thermal framework also asks for
reference to this table.
The idea beneath overclocking is to add "dangerous" frequency to the
frequency table only when necessary (and remove it when not needed).
In this way, the thermal framework (as it is done at our platform) will
decrease the frequency (according to thermal governor :-) ) to safe
level.
Overclocking is disabled in 2 ways (at our setup):
- thermal framework is here to help us
- lab governor disables the overclocking when favorable conditions are
gone.
One more remark - enabling tb_en_over_clk at sysfs (echo 1
> /sys/devices/system/cpu/cpu0/cpufreq/tb_en_over_clk)
adds overclock frequency to frequency table and updates policy.
It doesn't switch frequency to overclock value. This switching is done
only when proper conditions are in place (in ondemand or LAB).
>
> I hope this will be the most generic solution to your problem..
>
> What do you say?
Another issue is the current ondemand implementation:
It choose the highest load of all running cpus. This is not optimal in
terms of power consumption at multicore SoCs.
This is the ondemand legacy API (lb_check_cpu(int cpu, unsigned int
load_freq)).
I'm afraid, that ondemand would get polluted by the attempt to
implement LAB's logic into it.
In the end we would have "ondemand", which based on a runtime flag
value uses maximal load of a single processor, or counts number of
idle cpus (and filter them) to switch frequency.
To avoid such clash, we have decided to develop new governor with
minimal changes to core.
Such approach keeps logic clear.
--
Best regards,
Lukasz Majewski
Samsung R&D Poland (SRPOL) | Linux Platform Group
--
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
