On 28-10-15, 16:12, Rafael J. Wysocki wrote:
> So this is a changelog matching your patch:
>
> "gov_queue_work() acquires cpufreq_governor_lock to allow
> cpufreq_governor_stop()
> to drain delayed work items possibly scheduled on CPUs that share the policy
> with
> a CPU being taken offline.
>
On Wednesday, October 28, 2015 01:55:59 PM Viresh Kumar wrote:
> On 28-10-15, 08:10, Rafael J. Wysocki wrote:
> > I have a hard time figuring out what the patch is supposed to achieve from
> > the above.
>
> We had a problem earlier, where even after stopping the governor for a
> policy, the work
On 28-10-15, 08:10, Rafael J. Wysocki wrote:
> I have a hard time figuring out what the patch is supposed to achieve from
> the above.
We had a problem earlier, where even after stopping the governor for a
policy, the work was still queued for some of its CPUs.
We failed to understand the real pr
On Tuesday, October 13, 2015 01:39:04 PM Viresh Kumar wrote:
> cpufreq_governor_lock is abused by using it outside of cpufreq core,
> i.e. in cpufreq-governors. But we didn't had a better solution to the
> problem (described later) at that point of time, and following was the
> only acceptable solu
cpufreq_governor_lock is abused by using it outside of cpufreq core,
i.e. in cpufreq-governors. But we didn't had a better solution to the
problem (described later) at that point of time, and following was the
only acceptable solution:
6f1e4efd882e ("cpufreq: Fix timer/workqueue corruption by prot
5 matches
Mail list logo
