linux-kernel - Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq callbacks

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] [day] [month] [year] [list]

Date:   Mon, 31 Jul 2017 09:28:02 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Saravana Kannan <skannan@...eaurora.org>
Cc:     eas-dev@...ts.linaro.org, linux-pm@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Rafael Wysocki <rjw@...ysocki.net>,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        smuckle.linux@...il.com, Len Brown <lenb@...nel.org>
Subject: Re: [Eas-dev] [PATCH V3 1/3] sched: cpufreq: Allow remote cpufreq
 callbacks

On 28-07-17, 14:05, Saravana Kannan wrote:
> 1. I'm not saying that. I'm saying assuming CPUs can change the freq only on
> behalf of all the CPUs in the same policy is wrong. Again, the scheduler or
> governor shouldn't even be making any of that assumption. That's a CPUfreq
> driver problem.
> 
> 2. No, that is not the basis of the entire cpufreq core design. None of the
> existing CPUfreq code has any assumptions that only CPUs in a policy can
> change their frequency. It doesn't break in any way in system where any CPU
> can change any other CPU's frequency -- all Qualcomm chips are like that.
> It's only the recent scheduler notifier changes that are adding this
> additional limitation and breaking stuff for systems where any CPU can
> change any other CPU's frequency.

Can you please have a look at V5 and see f the solution proposed there would be
fine ?

-- 
viresh