linux-kernel - Re: [PATCH] cpufreq: Do not schedule policy update work in cpufreq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Mar 2016 13:30:00 +0700
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: Re: [PATCH] cpufreq: Do not schedule policy update work in
 cpufreq_resume()

On 16-03-16, 14:12, Rafael J. Wysocki wrote:
> No, it won't.  This might be applicable to other governors, but not to
> "performance" (look at what it does on _START instead of just
> guessing).
> 
> > So, your patch break things for sure.
> 
> I'm not actually sure it breaks anything.
> 
> Theoretically, it may, but practically?  Is there any system out there
> where it makes any difference?

AFAIU, this patch will break currently working governors.

-> cpufreq_resume()
  -> cpufreq_governor_performance(START)
    -> __cpufreq_driver_target(target_freq = policy->max)
    //policy->cur is already set to policy->max before suspend.
        if (target_freq == policy->cur)
                return 0;

And so, the real frequency stays to 500 MHz and policy->cur contains 1 GHz.

-- 
viresh