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. So it should be possible to configure the HW to generate the utilization monitoring events without excessive continuous CPU intervention. But I'm rather not going to work on the Exynos5422 SoC support at the moment. > 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. -- Regards, Sylwester
