Re: [PATCH V3 3/5] cpufreq: ondemand: queue work for policy->cpus together

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Wednesday, October 28, 2015 12:16:35 PM Viresh Kumar wrote:
> On 28-10-15, 07:38, Rafael J. Wysocki wrote:
> > On Tuesday, October 13, 2015 01:39:03 PM Viresh Kumar wrote:
> > > Currently update_sampling_rate() runs over each online CPU and
> > > cancels/queues work on it. Its very inefficient for the case where a
> > > single policy manages multiple CPUs, as they can be processed together.
> > 
> > In the case of one policy object shared between multiple CPUs, I'm
> > wondering why we don't use a single delayed work function for all of them
> > in the first place.  That would address the problem at the source instead
> > of dealing with the symptoms.
> 
> That's what we had long back. The problem is that the timers queued
> for cpufreq are deferrable and if the CPU, on which the timer is
> queued, goes idle, then the governor would halt. And there can be
> other CPUs in the policy->cpus group which are still running.

It looks like we shouldn't be using delayed works for this, really.

We should be using timer functions and normal work items.  Schedule the
timer function on all CPUs sharing the policy and then queue up the
work item from the first one that executes the timer.  Then make the
timer function bail out immediately until the work has completed and
re-schedule the timers from the work item.

Thanks,
Rafael