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
