Bug 465270

Summary: Plasma freezes or becomes very slow when there's heavy IO
Product: [Plasma] kwin Reporter: John <ilikefoss>
Component: generalAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED WORKSFORME    
Severity: normal CC: ilikefoss, marek321, postix
Priority: NOR    
Version First Reported In: 5.26.90   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: KDiskMark using a test folder on the Desktop for its work files

Description John 2023-02-04 14:08:37 UTC 
Created attachment 155935 [details]
KDiskMark using a test folder on the Desktop for its work files

SUMMARY
Plasma freezes or becomes very slow when there's heavy IO


STEPS TO REPRODUCE
1. Download KDiskMark from https://github.com/JonMagon/KDiskMark/releases/tag/3.1.2
2. Install Gdebi with: sudo apt install gdebi
3. Install KDiskMark with: sudo gdebi kdiskmark_3.1.2-ubuntu_amd64.deb
4. Create a folder on the Desktop, for example "Disk-test"
5. Open KDiskMark utility
6. From its 3rd configuration field (second drop-down) choose "Add a directory" and select previously created "Disk-test" or whatever named you decided to use.
7. Click on the "All" button to start testing the disk where KDE Plasma is installed
8. With this disk testing utility is running in background, try to do anything you would normally do

OBSERVED RESULT
As the disk benchmark utility runs in background, potentially creating a lot of Input / Output requests to the same disk that Plasma is using, I see that the desktop either freezes (becomes completely unresponsive), not being able to use even the mouse, or the effects of actions are delayed a lot.
So clicking on the start menu, clock widget, trying to open Dolphin, Kate, Konsole, System Settings seems to not be that responsive as it takes a lot of time until they open.
Navigating the System Settings by clicking on different menu items also takes a lot of time

EXPECTED RESULT
I expect that Plasma doesn't freeze no matter how much IO is in the background.
If it somehow needs to freeze, I expect that at least the mouse can be moved so I can move it where I want it to be next and click something that may not respond at that time, but that action will still be queued for when Plasma becomes responsive again so I don't just stay doing absolutely nothing.

Another thing that I expect is that at least the most common and used apps, like Dolphin, Kate, Konsole, Gwenview will be always available with no delay.

If one of them is open at that time and I'm doing something in it, like writing some text in Kate, I expect that the writing action will not be disturbed no matter how much IO is in the background.

Same for GwenView, I zoom in or out at the time, that has nothing to do with the disk, this action should not be disturbed by the heavy IO.

I expect that the RAM memory is better utilized is I don't need so much free memory if the desktop freezes or slows down, which makes me lose time.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma:
KDE Plasma Version: 5.26.90
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8

ADDITIONAL INFORMATION
If the freezes or slow downs of Plasma are not reproducible or not really obvious with KDiskMark running in the back, please try the following:
Use KDE Plasma from a HDD
Or from a USB flash drive
Or from a USB flash drive, but with a persistence file enable, like in my test (Lexar USB flash drive + 4GiB persistence file)

A USB flash drive + persistence file + KDiskMark running in background should make this problem really obvious.

I know that this looks like an edge case, but I intentionally decided to use the persistence file and KDiskMark at the same time to make it much more easily reproducible.

As both the freezes and slow down happened to me in the past even when I was using the internal memory.

At that time when it happened, I was using BTRFS or BTRFS + Zstd compression.

And when I was compressing / extracting many files from archives or I was copying / moving folders with many items inside from one place to another.
Comment 1 Vlad Zahorodnii 2023-02-06 09:18:46 UTC 
kwin periodically needs to access the disk, that's inevitable. We change the scheduling policy for the main thread and libinput thread to RR. Not sure that there's anything else we can do atm. If there are freezes, please check whether changing the file system type helps, ftr I haven't experienced severe issues with ext4.
Comment 2 Bug Janitor Service 2023-02-21 03:45:49 UTC 
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 3 Bug Janitor Service 2023-03-08 03:45:42 UTC 
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!
Comment 4 APTX 2025-08-20 15:59:01 UTC 
I hit this issue now. Should I report a new bug?

Operating System: Gentoo Linux 2.17
KDE Plasma Version: 6.4.4
KDE Frameworks Version: 6.17.0
Qt Version: 6.9.1
Kernel Version: 6.12.31-gentoo-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 32 × 13th Gen Intel® Core™ i9-13900K
Memory: 128 GiB of RAM (125.4 GiB usable)
Graphics Processor: NVIDIA RTX A4000
Manufacturer: ASUSTeK COMPUTER INC.

TL;DR

This seems to be https://bugs.kde.org/show_bug.cgi?id=487043 which hasn't been properly fixed (or it broke again). I have seen the change that disables the cache, but a cache is still being written. This issue will never be fully solved as long as blocking write operations are used in the main event loop.

Investigation

I ran some really heavy I/O, latency reported by zpool iostat -w can reach 17 seconds(!!) for writes (I may be able to tune this, but that is not the point). When plasma hangs for this long it's easy to just run "gdb -p $(pidof plasmashell)" and find out what it's doing:

(gdb) bt
#0  0x00007fed1fad6efe in linkat () at /usr/lib64/libc.so.6
#1  0x00007fed2020d93c in operator() (__closure=<optimized out>, dst=...) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qtemporaryfile.cpp:440
#2  operator() (__closure=__closure@entry=0x7ffc76942700, newName=<optimized out>) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qtemporaryfile.cpp:459
#3  0x00007fed202339d1 in QTemporaryFileEngine::materializeUnnamedFile (this=this@entry=0x557dd526da60, newName=..., mode=mode@entry=QTemporaryFileEngine::Overwrite) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qtemporaryfile.cpp:476
#4  0x00007fed20233adf in QTemporaryFileEngine::renameOverwrite (this=0x557dd526da60, newName=<optimized out>) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qtemporaryfile.cpp:390
#5  QTemporaryFileEngine::renameOverwrite (this=0x557dd526da60, newName=...) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qtemporaryfile.cpp:387
#6  0x00007fed20210133 in QSaveFile::commit (this=this@entry=0x7ffc76942830) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/io/qsavefile.cpp:320
#7  0x00007fed219d9068 in QSGRhiSupport::finalizePipelineCache (this=this@entry=0x7fed21d6d890 <QSGRhiSupport::instance_internal()::inst>, rhi=rhi@entry=0x557dd5145510, config=...) at /usr/src/debug/dev-qt/qtdeclarative-6.9.1-r2/qtdeclarative-everywhere-src-6.9.1/src/quick/scenegraph/qsgrhisupport.cpp:1098
#8  0x00007fed219da8a3 in QSGRhiSupport::destroyRhi (this=0x7fed21d6d890 <QSGRhiSupport::instance_internal()::inst>, rhi=0x557dd5145510, config=...) at /usr/src/debug/dev-qt/qtdeclarative-6.9.1-r2/qtdeclarative-everywhere-src-6.9.1/src/quick/scenegraph/qsgrhisupport.cpp:1301
#9  QSGRhiSupport::destroyRhi (this=0x7fed21d6d890 <QSGRhiSupport::instance_internal()::inst>, rhi=0x557dd5145510, config=...) at /usr/src/debug/dev-qt/qtdeclarative-6.9.1-r2/qtdeclarative-everywhere-src-6.9.1/src/quick/scenegraph/qsgrhisupport.cpp:1295
#10 QSGGuiThreadRenderLoop::windowDestroyed (this=0x557dca8b33a0, window=<optimized out>) at /usr/src/debug/dev-qt/qtdeclarative-6.9.1-r2/qtdeclarative-everywhere-src-6.9.1/src/quick/scenegraph/qsgrenderloop.cpp:371
#11 0x00007fed21abcf2c in QQuickWindow::~QQuickWindow (this=this@entry=0x557dd27e1cf0, __in_chrg=<optimized out>) at /usr/src/debug/dev-qt/qtdeclarative-6.9.1-r2/qtdeclarative-everywhere-src-6.9.1/src/quick/items/qquickwindow.cpp:1184
#12 0x00007fed22a199f4 in PlasmaQuick::PlasmaWindow::~PlasmaWindow (this=this@entry=0x557dd27e1cf0, __in_chrg=<optimized out>) at /usr/src/debug/kde-plasma/libplasma-6.4.4/libplasma-6.4.4/src/plasmaquick/plasmawindow.cpp:67
#13 0x00007fecfa7e2afd in NotificationWindow::~NotificationWindow (this=this@entry=0x557dd27e1cf0, __in_chrg=<optimized out>) at /usr/src/debug/kde-plasma/plasma-workspace-6.4.4/plasma-workspace-6.4.4/applets/notifications/notificationwindow.cpp:26
#14 0x00007fecfa7e1ab9 in QQmlPrivate::QQmlElement<NotificationWindow>::~QQmlElement (this=0x557dd27e1cf0, __in_chrg=<optimized out>) at /usr/include/qt6/QtQml/qqmlprivate.h:104
#15 QQmlPrivate::QQmlElement<NotificationWindow>::~QQmlElement (this=0x557dd27e1cf0, __in_chrg=<optimized out>) at /usr/include/qt6/QtQml/qqmlprivate.h:104
#16 0x00007fed201833ae in QObject::event (this=0x557dd27e1cf0, e=0x557dcf934f70) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qobject.cpp:1416
#17 0x00007fed22509a86 in QApplicationPrivate::notify_helper (this=<optimized out>, receiver=0x557dd27e1cf0, e=0x557dcf934f70) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/widgets/kernel/qapplication.cpp:3303
#18 0x00007fed201ff718 in QCoreApplication::notifyInternal2 (receiver=0x557dd27e1cf0, event=event@entry=0x557dcf934f70) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qcoreapplication.cpp:1106
#19 0x00007fed20225ec2 in QCoreApplication::sendEvent (receiver=<optimized out>, event=0x557dcf934f70) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qcoreapplication.cpp:1546
#20 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x557dc9e434a0) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qcoreapplication.cpp:1879
#21 0x00007fed1ffb0b27 in postEventSourceDispatch (s=0x557dc9e4c320) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qeventdispatcher_glib.cpp:246
#22 0x00007fed1e8b8d53 in g_main_dispatch (context=context@entry=0x7fed14000f00) at ../glib-2.84.3/glib/gmain.c:3398
#23 0x00007fed1e8bc067 in g_main_context_dispatch_unlocked (context=0x7fed14000f00) at ../glib-2.84.3/glib/gmain.c:4249
#24 g_main_context_iterate_unlocked (context=context@entry=0x7fed14000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib-2.84.3/glib/gmain.c:4314
#25 0x00007fed1e8bc7d0 in g_main_context_iteration (context=0x7fed14000f00, may_block=1) at ../glib-2.84.3/glib/gmain.c:4379
#26 0x00007fed1ffb0bb3 in QEventDispatcherGlib::processEvents (this=0x557dc9e4cb10, flags=...) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/kernel/qeventdispatcher_glib.cpp:399
#27 0x00007fed2022cde2 in QEventLoop::exec (this=this@entry=0x7ffc76942e00, flags=..., flags@entry=...) at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/global/qflags.h:77
#28 0x00007fed2022cf83 in QCoreApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/corelib/global/qflags.h:77
#29 0x00007fed2070ee70 in QGuiApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/gui/kernel/qguiapplication.cpp:1986
#30 0x00007fed22491059 in QApplication::exec () at /usr/src/debug/dev-qt/qtbase-6.9.1-r3/qtbase-everywhere-src-6.9.1/src/widgets/kernel/qapplication.cpp:2570
#31 0x0000557d8ad89f2d in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/kde-plasma/plasma-workspace-6.4.4/plasma-workspace-6.4.4/shell/main.cpp:188

In frame #7 finalizePipelineCache is called, even though it's supposedly disabled by https://invent.kde.org/plasma/kwin/-/commit/f700de56f8ae6c15c7fd7d18bdaf47bf1e21b219 (though to be honest, I don't know if it isn't some other cache). It's the bit that was changed as the fix in Qt at: https://codereview.qt-project.org/c/qt/qtdeclarative/+/564411

After looking around local variables in the various frames I found it is trying to create $HOME/.cache/plasmashell/qtpipelinecache-x86_64-little_endian-lp64/qqpc_opengl.ZujGbi
Comment 5 John 2025-09-10 12:56:29 UTC 
(In reply to Vlad Zahorodnii from comment #1)
> kwin periodically needs to access the disk, that's inevitable. We change the
> scheduling policy for the main thread and libinput thread to RR. Not sure
> that there's anything else we can do atm. If there are freezes, please check
> whether changing the file system type helps, ftr I haven't experienced
> severe issues with ext4.

It might be inevitable, but that doesn't mean that it's right to do that!
I have never seen Windows XP - 7 (the only ones that I used) to ever have the graphical interface and the interactions with it ever freeze or slow down.
There is definitely something plain wrong or unoptimized into what Kwin is doing since a disk IO, no matter how heavy it can make it freeze or slow down.
Plus, there's a reason why besides the disk(s) there's also RAM storage type.
Why isn't the whole Plasma session loaded entirely into RAM, where RAM storage is pleynty and then make Kwin sync (read / write) from RAM only and only from time to time write something to disk?
As for the filesystem, checking if this problems happen with another filesystem time is too hard to do as it requires a full back / restore + reinstallation of the OS, something I'm not prepared to do now.
And also I don't care if it's not happening on the old EXT4 one as I moved to BRFS for the extra features that it has and I don't plane to move back to EXT4 ever.
So, this problem is either fixed for BTRFS and comparable in features filesystems or I will ever consider it unfixed and a problem in KDE software.