Messages in this thread | | | Date | Wed, 10 Feb 2016 15:26:31 +0100 | Subject | Re: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks | From | "Rafael J. Wysocki" <> |
| |
On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli <juri.lelli@arm.com> wrote: > On 10/02/16 14:23, Rafael J. Wysocki wrote: >> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli <juri.lelli@arm.com> wrote: >> > Hi Rafael, >> > >> > On 09/02/16 21:05, Rafael J. Wysocki wrote: >> > >> > [...] >> > >> >> +/** >> >> + * cpufreq_update_util - Take a note about CPU utilization changes. >> >> + * @util: Current utilization. >> >> + * @max: Utilization ceiling. >> >> + * >> >> + * This function is called by the scheduler on every invocation of >> >> + * update_load_avg() on the CPU whose utilization is being updated. >> >> + */ >> >> +void cpufreq_update_util(unsigned long util, unsigned long max) >> >> +{ >> >> + struct update_util_data *data; >> >> + >> >> + rcu_read_lock(); >> >> + >> >> + data = rcu_dereference(*this_cpu_ptr(&cpufreq_update_util_data)); >> >> + if (data && data->func) >> >> + data->func(data, cpu_clock(smp_processor_id()), util, max); >> > >> > Are util and max used anywhere? >> >> They aren't yet, but they will be. >> >> Maybe not in this cycle (it it takes too much time to integrate the >> preliminary changes), but we definitely are going to use those >> numbers. >> > > Oh OK. However, I was under the impression that this set was only > proposing a way to get rid of timers and use the scheduler as heartbeat > for cpufreq governors. The governors' sample based approach wouldn't > change, though. Am I wrong in assuming this?
Your assumption is correct.
The sample-based approach doesn't change at this time, simply to avoid making too many changes in one go.
The next step, as I'm seeing it, would be to use the scheduler-provided utilization in the governor computations instead of the load estimation made by governors themselves.
> Also, is linux-pm/bleeding-edge the one I want to fetch to try this set out?
You can get it from there, but possibly with some changes unrelated to cpufreq.
You can also pull from the pm-cpufreq-test branch to get the cpufreq changes only.
Apart from that, I'm going resend the $subject set with updated patch [1/3] for completeness.
Thanks, Rafael
| |