Re: sched-freq locking

[Steve Muckle]

On 01/21/2016 05:21 PM, Rafael J. Wysocki wrote:
> 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.

I've been working on the locking in schedfreq (governor) and believe it
is now functionally correct. It'll get sent out in another RFC soon.

Having wrestled with that locking a bit I can appreciate the value of
potentially deprecating some or all of the cpufreq core. I'm also
fearful though of making the current task (creating a scheduler-based
CPU frequency scaling algorithm) more complex than it is already.

For that reason my preference would be to get the thing to a viable
state as a governor first, assuming that's possible, and then take on
restructuring to eliminate/deprecate unnecessary infrastructure. Does
this seem reasonable?

thanks,
Steve