Hey, guys!

I'm experiencing some hiccups on my plasma desktop while there's heavy seek IO on the HDD - for example seeding torrents or copying large files over partitions. For a second or two everything plasma-related becomes unresponsive (panels, desktop, etc), while other opened programs are not affected.

As I remember back in the KDE 3.x days, those tasks never made my desktop so unresponsive and the only thing that could cause similar behavior was a memory leak (of course they occurred rarely and were unrecoverable).

Mostly the IO activity isn't even on the same HDD, on which my Kubuntu system is installed. If I turn on compositing the desktop becomes more responsive under heavy IO load, but overall desktop experience under normal usage (web/flash browsing and scrolling for example) is slower. I guess the latter is because of my old PC configuration (Single core AMD Athlon 3000+, 1GB RAM, nVIDIA GeForce 9500GT), so mostly I'm using plasma/kwin without compositing.

I have the latest nVIDIA driver in the Kubuntu repositories, and tried tweaking xorg.conf (RenderAccel is always on + AddaRGBVisuals and some other options), but they only made difference with the compositing-on performance of plasma/KWin.

I truly appreciate KDE team's efforts to give users a choice of compositing or non-compositing desktop configuration, but I feel that the latter is having some performance troubles.

Using iotop to see which apps make frequent HDD requests, I noticed that the plasma-desktop process does such quite frequently (once every few seconds) and I'm not sure if that's normal. Although it shouldn't really matter, since the heavy IO work is on another HDD.

For the record I should mention that I'm using KDE 4.5.4, but I'm having this issue ever since I moved to KDE 4x from KDE 3.5.x.

Off topic, there's one bug that's been present since many KDE updates is that sometimes the appearance of hover-on tips and icon description popups, makes other part of the desktop (with the same size and shape) invisible, until they're redrawn. The bug is not present when compositing is active. (maybe I should provide a screenshot next time it happens, so you could see it)

Sorry for the very long post, but I tried to be accurate in my description.

Which applets are you using?

Currently I'm using CPU, Network and Memory usage history, a second panel with favourite apps and folder view. (+ 2 picture frames on a second plasma activity)

Can you reproduce this behaviour under a new user? Those applets should be ok for disk load.

Yes, it is reproduceable as a new user (tested), actually it's present ever since I'm using KDE 4.

Unfortunately I don't know why it is being unresponsive, but in my experience this is because the Kernel is swapping out programs unnecessarily.

Well it kinda' make sense, because in earlier versions of Kubuntu with KDE 3 I was wondering why my swap partition was always empty, and now for example when uTorrent is running for some time, the swap partition is ~20% used.

On the other side I just run a copy of large files across 2 HDD (on none of which is my system partition) and the plasma hiccups were present, but the swap % usage hasn't changed.

Is any way to see if the kernel is doing excessive swap-out?

You can try to see what process is using I/O with iotop.

Here's the iotop output while copying some .iso files as mentioned before.
plasma.avi [Donwload]

ps. at the bottom of the konsole screen there's a message saying:
CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO %

As far as I can tell, this is likely something happening in the kernel. Which version do you have, and can you check the kernel log (dmesg) while you're copying to see whether strange things crop up?

Well, there aren't any new lines in kernel log, produced during/after the transfer.

My Linux kernel version is: 2.6.32-27, but this issue has been present a long time ago (since Kubuntu 9.10)

If I have compositing turned on, the hiccups are not that much noticeable or gone at all.

the-mouse@linuxbox:~$ uname -a
Linux linuxbox 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

I'm using Kubuntu 10.04 right now.

I haven't seen any issues like that from kernels ranging from 2.6.34 to 2.6.37-rc8 (the one I'm using currently). I don't think it's got anything related to KDE, however. Some piece in the lower stack is misbehaving somehow.

And have you observed such behavior in kernels before 2.6.34?

If it was kernel related issue, wouldn't other programs suffer from the same issue? Because it's only plasma desktop and panels which are unresponsive, browsing (Chrome) is fast as normal.

I can't remember at the moment, but from iotop I only see KIO using the disk. Is the CPU going up when you're having I/O?

Yes, it goes up to 100%. But it's been that way in 2008 with Kubuntu Dapper (and as I recall on another PC configuration), but it had impact on KDE 3 performance only if the transfer was on the same HDD (containing the system partition), which is acceptable.

As I added another HDD and tested copying large files to it, the CPU usage went 100% (again), but there was no impact on KDE's performance.

Back then I started a topic in ubuntuforums.org (I was concerned about the high CPU usage) but it turned out to be ok.

As Sencer (from ubuntuforums.org) suggested here's the output of vmstat 1 10:

Idle system:

Code: Select all

the-mouse@linuxbox:~$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0  33968 135828  23756 331196    0    3   583   524  314  834 17  4 77  2
 0  0  33968 135828  23756 331184    0    0     0     0  136  192  1  0 99  0
 2  0  33968 135780  23756 331184    0    0     0     0  153  282  5  1 94  0
 0  0  33968 135828  23756 331184    0    0     0     0  173  380  9  2 89  0
 0  0  33968 135828  23756 331184    0    0     0     0  144  260  1  1 98  0
 1  0  33968 135828  23756 331184    0    0     0     0  135  188  0  1 99  0
 0  0  33968 135828  23764 331176    0    0     0    12  147  212  1  0 97  2
 0  0  33968 135828  23764 331184    0    0     0     0  132  188  0  0 100  0
 0  0  33968 135828  23764 331184    0    0     0     0  140  199  1  1 98  0
 0  0  33968 135828  23772 331176    0    0     0    40  143  190  3  0 96  1


With copy operation in progress:

Code: Select all

the-mouse@linuxbox:~$ vmstat 1 10
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  1  34224  14960   8428 465168    0    3   587   526  314  835 17  4 77  2
 1  0  34224  14936   8508 464500    0    0 37416 36864  575 3080 13 45  0 41
 1  1  34224  15156   8464 464932    0    0 37412 36908  571 2965 13 46  0 42
 1  0  34224  14748   8532 465400    0    0 36388 36864  554 2960 10 41  0 48
 1  2  34224  14832   8936 463348    0    0 36904 97484  594 3046 13 48  0 40
 1  0  34224  16124   9008 463844    0    0 37156   300  615 3190 14 44  0 42
 0  1  34224  13420   9072 465840    0    0 36900 16904  511 2922 13 44  0 43
 0  1  34224  14908   9144 464784    0    0 36644 36864  575 3006 11 49  0 40
 2  1  34224  14660   9220 464828    0    0 37172 36864  570 2987 15 43  0 43
 0  1  34224  13544   9304 465848    0    0 37680 36884  569 3022 11 43  0 45


einar wrote:...from iotop I only see KIO using the disk. Is the CPU going up when you're having I/O?

Well, besides KIO there're also regular (in time) I/O requests by:
plasma-desktop, [sync_supers], [jbd2/sdb7-8], [flush-8:16], rsyslogd -c4
(as seen in the video)

They appear in regular periods of time, which match the plasma 'hiccups' in time.