https://bugs.kde.org/show_bug.cgi?id=478457
--- Comment #5 from Harald Sitter <sit...@kde.org> --- (In reply to Eddie J Carswell II from comment #4) > (In reply to Harald Sitter from comment #3) > > > no high CPU/IOwait/Network from kioslave5 (media previews still working) > > > > You may need to explain this expectation in greater detail. How do you > > reconcile remote-IO-without-wait-time with having to access remote data, as > > would be the case during preview generation? At face value there's always an > > unknown amount of wait time, because we don't know network throughput and > > latency, and then remote drive throughput and latency. Or put simply: the > > only way not to wait is to not read data; when reading data we need to wait > > for the IO. > > I meant the overall system IOwait percentage seems to get rather high > (sometimes over 30%) and can sometimes cause other processes to stutter and > lag. If it is the system io wait that is high, then how can you tell it's kioslave5 causing it? Also, how are you measuring this? > My main system drive is an NVMe (LVM on LUKS) so it's rather odd that > kioslave could be causing that much of an issue. I haven't messed with any > kernel parameters or changed the scheduler settings from stock Fedora > defaults here. I'll also note that it's not network bandwidth being the > issue, but the disk read speed of the remote server (spinning rust, also see > high iowait when I checked it during the issue) that causes the local iowait > for kioslave. > > It also seems weird to me that being bottlenecked on IO to a network > filesystem can still cause visible lag for other processes only doing local > IO, unless there's a shared IO pipeline for all mounted filesystems? Not > sure why that is happening exactly. It is certainly weird, but from what you describe your problem seems to be more with the kernel and its io scheduler than with kioslave5. The solution here really shouldn't be don't-do-IO - that's like saying don't turn your computer on, then you also don't have io wait. > Either way, reducing the process IO > priority could be helpful here (like maybe idle priority) to reduce the > impact. > > > > A naive analysis would seem to suggest there are less invasive and > > > resource intensive ways to generate media previews > > > > Such as? > > I haven't looked at the code, so my suggestions are based on observed > behavior. > > - I've already mentioned lowering IO priority so it doesn't push out other > processes. I feel that this would be a workload perfectly suited to running > at idle priority, since its an ancillary function that shouldn't impair the > primary functionality of the program (being a file browser). idle priority unfortunately won't work because it is subject to starvation. Users do expect previews to be generated eventually. > - Is there anything we can do to reduce the amount of reading necessary to > generate a thumbnail for a video file? Doesn't look like it. We already read very little. > - I also notice that hovering will show a mini preview slideshow, so the > program is probably reading a lot further into the file to grab those > thumbnails. Maybe this behavior could be made tunable "disable deep > thumbnail generation" or something. Maybe it should be off by default for > non-local files. We jump through the file as a matter of fact, it's fairly cheap. There already is a setting for disabling previews on remotes, the sequence generation isn't nearly expensive enough to justify yet another setting. > - I mentioned in another comment that renaming or moving a file seems to > invalidate the thumbnail and trigger another generation. Could we link the > generated thumbnails with a more persistent identifier? File hash may not be > useful since that requires reading the file. Maybe the inode? I'm not sure > if an equivalent to inodes would even exist for SMB (NFS does expose > persistent inodes). How do you rename the file? Via dolphin or terminal? > - Is this process descending automatically to child directories to be more > thorough? That makes even browsing the level above a large video directory > problematic, and it doesn't seem to quit when I'm no longer in the vicinity > of that directory tree. When you have directory previews enabled, then yes it'd naturally have to create previews for the first couple files in subdirectories. Otherwise not. -- You are receiving this mail because: You are watching all bug changes.
