Prevent sysfs read latency from interfering with GUI updates
This patch moves /sys/.../scaling_cur_freq
reads to a thread that is separate from the GUI thread. In addition, in case the read latency is longer than the refresh time of the cpufreq plugin, the plugin will not schedule a new sysfs
read until the currently running batch of sysfs
reads terminates.
The implementation protects data shared among threads using mutexes. The data protected by a single mutex is very small (less than 100 bytes). It is improbable for the timing of the critical sections in different threads to interfere with each other.
Some examples of reading CPU info from sysfs
files:
-
Ryzen 7 3700X (8 cores, 16 threads): latency of a batch of 16 reads of
/sys/.../scaling_cur_freq
files: up to 200 milliseconds -
Ryzen 9 3900X (12 cores, 24 threads): latency of a batch of 24 reads of
/sys/.../scaling_cur_freq
files: up to 800 milliseconds -
The
sysfs
latency depends on the frequency of the reads. If reading more than 2 times per second then the latency of each batch of reads is 1 ms. But if reading less than 1 time per second then the latency is much longer: 200ms or 800ms.
Closes: #15 (closed)