On 10/02/16 14:23, Rafael J. Wysocki wrote: > On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli <juri.le...@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? Also, is linux-pm/bleeding-edge the one I want to fetch to try this set out? Thanks, - Juri