| 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
| ||
|
Date: Wed, 20 Jan 2016 17:39:14 -0800 From: Steve Muckle <steve.muckle@...aro.org> To: "Rafael J. Wysocki" <rjw@...ysocki.net> Cc: Michael Turquette <mturquette@...libre.com>, Vincent Guittot <vincent.guittot@...aro.org>, Juri Lelli <Juri.Lelli@....com>, Patrick Bellasi <patrick.bellasi@....com>, Morten Rasmussen <morten.rasmussen@....com>, Dietmar Eggemann <dietmar.eggemann@....com>, Viresh Kumar <viresh.kumar@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>, Peter Zijlstra <peterz@...radead.org> Subject: Re: sched-freq locking On 01/20/2016 05:22 PM, Rafael J. Wysocki wrote: > One comment here (which may be a bit off in which case please ignore it). > > You seem to be thinking that sched-freq needs to be a cpufreq governor > and thus be handled in the same way as ondemand, for example. That's true, I hadn't really given much thought to the alternative you mention below. > > However, this doesn't have to be the case in principle. For example, > if we have a special driver callback specifically to work with sched-freq, > it may just use that callback and bypass (almost) all of the usual > cpufreq mechanics. This way you may avoid worrying about the governor > locking and related ugliness entirely. That sounds good but I'm worried about other consequences of taking cpufreq out of the loop. For example wouldn't we need a new way for something like thermal to set frequency limits? thanks, steve
Powered by blists - more mailing lists