Messages in this thread | | | Date | Fri, 24 May 2013 14:21:30 +0530 | Subject | Re: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results | From | Viresh Kumar <> |
| |
On 24 May 2013 14:00, Lukasz Majewski <l.majewski@samsung.com> 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.
I hope this will be the most generic solution to your problem..
What do you say?
-- viresh
| |