linux-kernel - Re: sched-freq locking

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 22 Jan 2016 02:21:50 +0100
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Juri Lelli <Juri.Lelli@....com>
Cc:	Steve Muckle <steve.muckle@...aro.org>,
	Michael Turquette <mturquette@...libre.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	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>,
	Javi Merino <Javi.Merino@....com>,
	Punit Agrawal <punit.agrawal@....com>
Subject: Re: sched-freq locking

On Thursday, January 21, 2016 10:49:58 AM Juri Lelli wrote:
> [+Punit, Javi]
> 
> Hi Rafael,
> 
> On 21/01/16 02:46, Rafael J. Wysocki wrote:
> > 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.
> > 
> 
> Yes, that's an interesting alternative that we have to think through.
> 
> > Maybe we can keep the interface for those things unchanged, but handle it
> > differently under the hood?
> > 
> 
> Let me see if I understand what you are proposing :). If we don't want
> to duplicate too many things, maybe it is still feasible to just use
> existing cpufreq mechanics to handle hotplug, sysfs, thermal, etc. (with
> possibly minor modifications to be notified of events) and only create a
> new method to ask the driver for frequency changes, since we will have
> replicated policy and freq_table information inside sched-freq.  Is that
> what you were also thinking of by saying "bypass (almost) all the usual
> cpufreq mechanics"? :)

Yes, it is.

Thanks,
Rafael