https://bugs.kde.org/show_bug.cgi?id=400704
--- Comment #6 from Mayeul Cantan <mayeul.can...@live.fr> --- (In reply to Axel Braun from comment #5) > (In reply to Stefan Brüns from comment #4) > > > Even with low priority, the kernel eventually has to flush the write > > buffers, causing the high I/O latency for other tasks. > > Should the I/O traffic from higher prioritized tasks not processed before as > well? I mean, if baloo does not get any CPU time, how can it create such a > high traffic? Looking at iotop, it is mostly a factor 100 to 1000 higher > than other tasks.... >From this link, it seems to be the case (though a link to the kernel source would have been nicer) https://unix.stackexchange.com/questions/153505/how-disk-io-priority-is-related-with-process-priority > io_priority = (cpu_nice + 20) / 5 In my case, though, it was always baloorunner showing at 99.99 % I/O in iotop. baloo_file_extractor would also run sometimes, but with a lesser subjective impact on performance. Setting baloorunner to a lower priority using ionice seemed to improve things quite a bit, although I would have to confirm it. I get the point about needing to flush the cache at some point. Unfortunately, I am at a loss as to why my mouse freezes because of it. I am on a 8 (16 SMT)-core CPU, and only a couple are used by the kernel. CPU <-> RAM bandwidth should not be the limiting factor, and other threads should be able to go trough when CPU <-> Sata Controller is being waited on. Maybe it has to do with interrupts comming in from the SATA controller? -- You are receiving this mail because: You are watching all bug changes.
