Re: brocken devfreq simple_ondemand for Odroid XU3/4?

[Lukasz Luba]

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