https://bugs.kde.org/show_bug.cgi?id=478457
--- Comment #12 from Eddie J Carswell II <eddiecarswel...@yahoo.com> --- (In reply to Harald Sitter from comment #8) > You've basically taken away the CPU weight from all KIO IO by doing this. Ah I see, I've tweaked it to only impact the thumbnail task: > $ cat /usr/libexec/kf5/kioslave5 > #!/bin/sh > [ $2 != "thumbnail" ] && exec $0.orig "$@" || exec nice -n 19 ionice -c 3 > $0.orig "$@" That should minimize any side effects of this hack. (In reply to Harald Sitter from comment #9) > After some research I'm even less convinced of this. From what I can tell > cifs is not subject to any IO scheduling what with being network based. IO > scheduling only comes into play when the request is routed into a block > device. cifs communication directly goes out into the network stack and > would be subject to the queuing discipline, which seems not interested in > IOPRIO. Perhaps this actually makes all perfect sense. We request a PNG to > create a preview, cifs is happy to oblige and issues (multiple concurrent?) > network requests, the remote is dreadfully slow and iowaiting on its disk, > translating to us iowaiting on the network sockets coming back with the > data. I can kind of replicate this by cgroup limiting smbd IO, but even with > very aggressive limits my system stays responsive. So, I'm rather thinking > there is a problem with your kernel/configuration. Hmm do you have any ideas on what would be impacting this? I'm running Fedora stock kernel 6.6.6-100.fc38.x86_64 and the scheduling settings are default, as far as I can tell. > Indeed, you are accessing it through the file:// protocol. That makes it > inherently local. I suppose I'll just have to deal with that behavior then, or probably set a file size limit acceptable for local and remote files. > I have the suspicion that this has to do with why things are misbehaving for > you to begin with. smb:// is performing close to the same transfer speed as > windows, if it doesn't for you that points at a problem elsewhere. Straight transfer speed was not the main issue. Aside from being unable to use the protocol path outside of KDE programs (e.g. terminal), there was also the slower response times enumerating directories, moving/renaming files, and sometimes dolphin would even go unresponsive for a few seconds. I tested a file transfer with the fstab mount and using smb:// and the throughput was similar. The transfer speed sending a ~1GB video file to the server via mount path was 60s (+20s for server IO to settle), and protocol path was 45s (+40s for server IO to settle). Pulling that file took 22s via mount path and 35s via protocol path (in both cases writing to an NVMe, waiting for all IO to settle between). To remove the disks from the equation, I mounted a ramdisk at both ends and did the test again. Download from the mount path was 20s, protocol path 30s. Upload to the mount path was 40s, protocol path was 50s. So closer numbers this time. It appears to me that in cases where both ends are nearly idle, they aren't that different, but when the server is under higher IO loads, the mount seems to behave better (more responsive, doesn't put the server under as high an IO load). > Perhaps let's get our ducks in a row > > What's the output of > $ tc qdisc show > qdisc noqueue 0: dev lo root refcnt 2 > qdisc noqueue 0: dev wlan0 root refcnt 2 > qdisc fq_codel 0: dev enp10s0u1u2 root refcnt 2 limit 10240p flows > 1024 > quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn > drop_batch 64 > qdisc noqueue 0: dev virbr0 root refcnt 2 > qdisc noqueue 8005: dev vnet4 root refcnt 2 > $ ls -lah "$(qtpaths --plugin-dir)/kf5/thumbcreator" > total 752K > drwxr-xr-x. 2 root root 4.0K Nov 28 06:55 . > drwxr-xr-x. 21 root root 4.0K Nov 13 06:50 .. > -rwxr-xr-x. 1 root root 44K Nov 13 19:00 audiothumbnail.so > -rwxr-xr-x. 1 root root 28K Nov 13 19:00 blenderthumbnail.so > -rwxr-xr-x. 1 root root 40K Nov 13 19:00 comicbookthumbnail.so > -rwxr-xr-x. 1 root root 20K Nov 13 19:00 cursorthumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 djvuthumbnail.so > -rwxr-xr-x. 1 root root 44K Nov 13 19:00 ebookthumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 exrthumbnail.so > -rwxr-xr-x. 1 root root 81K Nov 13 19:00 ffmpegthumbs.so > -rwxr-xr-x. 1 root root 32K Nov 24 19:00 fontthumbnail.so > -rwxr-xr-x. 1 root root 77K Nov 13 19:00 gsthumbnail.so > -rwxr-xr-x. 1 root root 24K Nov 13 19:00 imagethumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 jpegthumbnail.so > -rwxr-xr-x. 1 root root 20K Nov 13 19:00 kraorathumbnail.so > -rwxr-xr-x. 1 root root 41K Nov 13 19:00 mltpreview.so > -rwxr-xr-x. 1 root root 20K Nov 13 19:00 mobithumbnail.so > -rwxr-xr-x. 1 root root 28K Nov 13 19:00 opendocumentthumbnail.so > -rwxr-xr-x. 1 root root 24K Nov 13 19:00 rawthumbnail.so > -rwxr-xr-x. 1 root root 20K Nov 13 19:00 svgthumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 textthumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 windowsexethumbnail.so > -rwxr-xr-x. 1 root root 32K Nov 13 19:00 windowsimagethumbnail.so > Also please follow > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Debugging_IOSlaves/ > Debugging_kio_smb#Reporting_Bugs and include 'Logging with libsmbclient > debug output' I'll attach the stdout and stderr log (apparently the debug output ended up in both places). During this time, I browsed a directory containing a few dozen twitch stream captures. If there's anything in particular you want me to try or a more rigorous test, let me know. -- You are receiving this mail because: You are watching all bug changes.
