Re: [PATCH v3 9/10] cpufreq: sched: Re-introduce cpufreq_update_util()

Rafael J. Wysocki
2016-03-04T21:27:51Z

On Fri, Mar 4, 2016 at 10:21 PM, Steve Muckle <steve.muckle@linaro.org> wrote:
> On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote:
>> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
>> +{
>> + struct freq_update_hook *hook;
>> +
>> +#ifdef CONFIG_LOCKDEP
>> + WARN_ON(debug_locks && !rcu_read_lock_sched_held());
>> +#endif
>> +
>> + hook = rcu_dereference_sched(*this_cpu_ptr(&cpufreq_freq_update_hook));
>> + /*
>> + * If this isn't inside of an RCU-sched read-side critical section, hook
>> + * may become NULL after the check below.
>> + */
>> + if (hook) {
>> + if (hook->update_util)
>> + hook->update_util(hook, time, util, max);
>> + else
>> + hook->func(hook, time);
>> + }
>
> Is it worth having two hook types?

Well, that's why I said "maybe over the top" in the changelog comments. :-)

If we want to isolate the "old" governors from util/max entirely, then yes.

If we don't care that much, then no.

I'm open to both possibilities.

Thanks,
Rafael