Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Viresh Kumar
On 08-09-15, 07:41, Viresh Kumar wrote: > > > next_sampling = jiffies + usecs_to_jiffies(new_rate); > > > appointed_at = dbs_info->cdbs.dwork.timer.expires; > > > > For that to work we always need to do stuff for policy->cpus in sync. > > Do we? > > Hmm, we are not in 100%

Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Viresh Kumar
On 08-09-15, 03:33, Rafael J. Wysocki wrote: > > + /* Make sure the work is not canceled on policy->cpus */ > > I'm not sure what scenario can lead to that. Care to explain? CPUFREQ_GOV_STOP event called for the policy and so all its works are in canceled state. > > + if

Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Rafael J. Wysocki
On Monday, July 27, 2015 05:58:11 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. > > Also drop the unnecessary

Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Rafael J. Wysocki
On Monday, July 27, 2015 05:58:11 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. > > Also drop the unnecessary

Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Viresh Kumar
On 08-09-15, 07:41, Viresh Kumar wrote: > > > next_sampling = jiffies + usecs_to_jiffies(new_rate); > > > appointed_at = dbs_info->cdbs.dwork.timer.expires; > > > > For that to work we always need to do stuff for policy->cpus in sync. > > Do we? > > Hmm, we are not in 100%

Re: [PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-09-07 Thread Viresh Kumar
On 08-09-15, 03:33, Rafael J. Wysocki wrote: > > + /* Make sure the work is not canceled on policy->cpus */ > > I'm not sure what scenario can lead to that. Care to explain? CPUFREQ_GOV_STOP event called for the policy and so all its works are in canceled state. > > + if

[PATCH V2 6/9] cpufreq: ondemand: queue work for policy->cpus together

2015-07-27 Thread Viresh Kumar
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. Also drop the unnecessary cancel_delayed_work_sync() as we are doing a mod_delayed_work_on()

[PATCH V2 6/9] cpufreq: ondemand: queue work for policy-cpus together

2015-07-27 Thread Viresh Kumar
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. Also drop the unnecessary cancel_delayed_work_sync() as we are doing a mod_delayed_work_on()