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% syn
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 (!d
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 c
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() i
4 matches
Mail list logo