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, 21 Jan 2016 02:46:05 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Steve Muckle <steve.muckle@...aro.org>
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 Wednesday, January 20, 2016 05:39:14 PM Steve Muckle wrote:
> 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?

I don't know from the top of my head, but that's at least worth investigating.

Maybe we can keep the interface for those things unchanged, but handle it
differently under the hood?

Thanks,
Rafael

Powered by blists - more mailing lists