Re: sched-freq locking

[Rafael J. Wysocki]

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