Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

On 30-11-15, 13:05, Lucas Stach wrote: > I don't want to block this patch on that, but maybe as a thought for > further consideration: Wouldn't it make sense to use a single unbound > deferrable work item for this? There was some work to make this possible > already: "timer: make deferrable cpu

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Am Donnerstag, den 29.10.2015, 17:57 +0530 schrieb Viresh Kumar: > cpufreq governors evaluate load at sampling rate and based on that they > update frequency for a group of CPUs belonging to the same cpufreq > policy. > > This is required to be done in a single thread for all policy->cpus, but >

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Am Donnerstag, den 29.10.2015, 17:57 +0530 schrieb Viresh Kumar: > cpufreq governors evaluate load at sampling rate and based on that they > update frequency for a group of CPUs belonging to the same cpufreq > policy. > > This is required to be done in a single thread for all policy->cpus, but >

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

On 30-11-15, 13:05, Lucas Stach wrote: > I don't want to block this patch on that, but maybe as a thought for > further consideration: Wouldn't it make sense to use a single unbound > deferrable work item for this? There was some work to make this possible > already: "timer: make deferrable cpu

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Viresh, On 30 October 2015 at 22:36, Viresh Kumar wrote: > Hi Ashwin, > > On 30-10-15, 16:46, Ashwin Chaugule wrote: >> On 29 October 2015 at 08:27, Viresh Kumar wrote: >> > This could be made lightweight by keeping per-cpu deferred timers with a >> > single work item, which is scheduled by

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Viresh, On 30 October 2015 at 22:36, Viresh Kumar wrote: > Hi Ashwin, > > On 30-10-15, 16:46, Ashwin Chaugule wrote: >> On 29 October 2015 at 08:27, Viresh Kumar wrote: >> > This could be made lightweight by keeping per-cpu deferred timers

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Ashwin, On 30-10-15, 16:46, Ashwin Chaugule wrote: > On 29 October 2015 at 08:27, Viresh Kumar wrote: > > This could be made lightweight by keeping per-cpu deferred timers with a > > single work item, which is scheduled by the first timer that expires. > > Single shared work item - would

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Viresh, On 29 October 2015 at 08:27, Viresh Kumar wrote: > cpufreq governors evaluate load at sampling rate and based on that they > update frequency for a group of CPUs belonging to the same cpufreq > policy. > > This is required to be done in a single thread for all policy->cpus, but >

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Viresh, On 29 October 2015 at 08:27, Viresh Kumar wrote: > cpufreq governors evaluate load at sampling rate and based on that they > update frequency for a group of CPUs belonging to the same cpufreq > policy. > > This is required to be done in a single thread for all

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Ashwin, On 30-10-15, 16:46, Ashwin Chaugule wrote: > On 29 October 2015 at 08:27, Viresh Kumar wrote: > > This could be made lightweight by keeping per-cpu deferred timers with a > > single work item, which is scheduled by the first timer that expires. > > Single

[PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

cpufreq governors evaluate load at sampling rate and based on that they update frequency for a group of CPUs belonging to the same cpufreq policy. This is required to be done in a single thread for all policy->cpus, but because we don't want to wakeup idle CPUs to do just that, we use deferrable

[PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

cpufreq governors evaluate load at sampling rate and based on that they update frequency for a group of CPUs belonging to the same cpufreq policy. This is required to be done in a single thread for all policy->cpus, but because we don't want to wakeup idle CPUs to do just that, we use deferrable