https://bugs.kde.org/show_bug.cgi?id=434877
--- Comment #30 from Mark <mark...@gmail.com> --- Hi, So since my last post i've been hacking away at this (taking btop as starting point) to figure out how accurate (as in how many snapshots per second) i can do without progress monitoring itself becomes noise in the monitoring making the monitoring itself more complicated. Turn out that reading the data from all stat files for each pid (so /proc/1/stat, /proc/2/stat, /proc/3/stat, ...) is amazingly fast. I tried this on my machine with about 350 running processes and reading all those files every 100ms (so 10x per second) is not any significant CPU usage at all. As in, it barely even registers! It's even hard to say how much CPU it uses as it's essentially 0% with occasional very short jumps to 2%. I tried this with normal open/read/close and with io_uring! There's hardly any difference! The number of syscalls/second (350 processes with open/read/close = 350*3=1050 syscalls per second when instrumenting once per second. I reduced this to about 100 syscalls with io_uring (io_uring_enter is the one mostly used, it's to submit data to "the ring"), again when instrumenting once per second. io_uring vs plain open/read/close? Don't bother! The amount of extra code you need (and the massive added code complexity) is not worth it. The benefits in terms of performance are negligible at best. So again, io_uring is not worth it! Just wanted to put this on here to prevent someone from wasting hours implementing io_uring just to discover that it's not gonna matter at all. The progress monitor is doing something, i don't know what, incredible inefficient but IO is quite likely not the culprit. Unless the wrong files are polled of course. -- You are receiving this mail because: You are watching all bug changes.
