Hi All, On 24.06.2020 12:32, Lukasz Luba wrote: > I had issues with devfreq governor which wasn't called by devfreq > workqueue. The old DELAYED vs DEFERRED work discussions and my patches > for it [1]. If the CPU which scheduled the next work went idle, the > devfreq workqueue will not be kicked and devfreq governor won't check > DMC status and will not decide to decrease the frequency based on low > busy_time. > The same applies for going up with the frequency. They both are > done by the governor but the workqueue must be scheduled periodically. As I have been working on resolving the video mixer IOMMU fault issue described here: https://patchwork.kernel.org/patch/10861757 I did some investigation of the devfreq operation, mostly on Odroid U3. My conclusions are similar to what Lukasz says above. I would like to add that broken scheduling of the performance counters read and the devfreq updates seems to have one more serious implication. In each call, which normally should happen periodically with fixed interval we stop the counters, read counter values and start the counters again. But if period between calls becomes long enough to let any of the counters overflow, we will get wrong performance measurement results. My observations are that the workqueue job can be suspended for several seconds and conditions for the counter overflow occur sooner or later, depending among others on the CPUs load. Wrong bus load measurement can lead to setting too low interconnect bus clock frequency and then bad things happen in peripheral devices. I agree the workqueue issue needs to be fixed. I have some WIP code to use the performance counters overflow interrupts instead of SW polling and with that the interconnect bus clock control seems to work much better. -- Regards, Sylwester
