Re: brocken devfreq simple_ondemand for Odroid XU3/4?

[Lukasz Luba <lukasz.luba@arm.com>]

On 6/26/20 6:50 PM, Sylwester Nawrocki wrote:
> Hi Lukasz,
> 
> On 25.06.2020 12:02, Lukasz Luba wrote:
>> Regarding the 'performance counters overflow interrupts' there is one
>> thing worth to keep in mind: variable utilization and frequency.
>> For example, in order to make a conclusion in algorithm deciding that
>> the device should increase or decrease the frequency, we fix the period
>> of observation, i.e. to 500ms. That can cause the long delay if the
>> utilization of the device suddenly drops. For example we set an
>> overflow threshold to value i.e. 1000 and we know that at 1000MHz
>> and full utilization (100%) the counter will reach that threshold
>> after 500ms (which we want, because we don't want too many interrupts
>> per sec). What if suddenly utilization drops to 2% (i.e. from 5GB/s
>> to 250MB/s (what if it drops to 25MB/s?!)), the counter will reach the
>> threshold after 50*500ms = 25s. It is impossible just for the counters
>> to predict next utilization and adjust the threshold.
> 
> Agreed, that's in case when we use just the performance counter (PMCNT)
> overflow interrupts. In my experiments I used the (total) cycle counter
> (CCNT) overflow interrupts. As that counter is clocked with fixed rate
> between devfreq updates it can be used as a timer by pre-loading it with
> initial value depending on current bus frequency. But we could as well
> use some reliable system timer mechanism to generate periodic events.
> I was hoping to use the cycle counter to generate low frequency monitor
> events and the actual performance counters overflow interrupts to detect
> any sudden changes of utilization. However, it seems it cannot be done
> with as simple performance counters HW architecture as on Exynos4412.
> It looks like on Exynos5422 we have all what is needed, there is more
> flexibility in selecting the counter source signal, e.g. each counter
> can be a clock cycle counter or can count various bus events related to
> actual utilization. Moreover, we could configure the counter gating period
> and alarm interrupts are available for when the counter value drops below
> configured MIN threshold or exceeds configured MAX value.

I see. I don't have TRM for Exynos5422 so couldn't see that. I also
have to keep in mind other platforms which might not have this feature.

> 
> So it should be possible to configure the HW to generate the utilization
> monitoring events without excessive continuous CPU intervention.

I agree, that would be desirable especially for low load in the system.

> But I'm rather not going to work on the Exynos5422 SoC support at the moment.

I see.

> 
>> To address that, we still need to have another mechanism (like watchdog)
>> which will be triggered just to check if the threshold needs adjustment.
>> This mechanism can be a local timer in the driver or a framework
>> timer running kind of 'for loop' on all this type of devices (like
>> the scheduled workqueue). In both cases in the system there will be
>> interrupts, timers (even at workqueues) and scheduling.
>> The approach to force developers to implement their local watchdog
>> timers (or workqueues) in drivers is IMHO wrong and that's why we have
>> frameworks.
> 
> Yes, it should be also possible in the framework to use the counter alarm
> events where the hardware is advanced enough, in order to avoid excessive
> SW polling.

Looks promising, but that would need more plumbing I assume.

Regards,
Lukasz

> 
> --
> Regards,
> Sylwester
>