Comment 2 for bug 221437

Ritesh Raj Sarraf (rrs) wrote :

Attached is the output of iostat when the copy was taking place.
Interesting thing to notice is that the I/O starts up at a good speed, copies at good speed and then eventually the performance starts degrading.

I'm also adding the output of top which is pretty interesting....
rrs@learner:~$ top
top - 02:17:22 up 4:11, 1 user, load average: 8.93, 8.99, 5.34
Tasks: 152 total, 4 running, 148 sleeping, 0 stopped, 0 zombie
Cpu(s): 61.3%us, 28.9%sy, 1.2%ni, 0.0%id, 0.0%wa, 0.5%hi, 8.1%si, 0.0%st
Mem: 2074320k total, 2018768k used, 55552k free, 3588k buffers
Swap: 2621432k total, 38436k used, 2582996k free, 1088672k cached

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 6460 rrs 20 0 38224 19m 15m R 57 1.0 11:29.92 kded
 7419 rrs 20 0 785m 545m 35m R 49 26.9 7:01.30 kontact
13698 rrs 20 0 181m 67m 26m S 38 3.3 0:46.24 firefox
 6613 rrs 20 0 95940 47m 25m S 20 2.4 2:50.79 kopete
 5585 root 20 0 79964 51m 5468 R 16 2.6 5:09.88 Xorg
25743 rrs 20 0 2308 1144 856 R 15 0.1 0:04.24 top
 6824 rrs 20 0 34048 16m 11m S 7 0.8 0:38.62 konsole
 2663 root 15 -5 0 0 0 S 5 0.0 8:57.19 kcryptd
18011 rrs 39 19 93568 30m 10m S 3 1.5 3:50.96 beagled-helper
   48 root 15 -5 0 0 0 S 1 0.0 0:09.40 kblockd/1
 6455 rrs 20 0 25912 3260 1688 S 1 0.2 0:18.60 dcopserver
 6637 rrs 20 0 35012 3724 2920 S 1 0.2 0:03.50 pulseaudio
 6642 rrs 20 0 31892 11m 9148 S 1 0.6 0:03.48 klipper
 6522 rrs 20 0 31624 8160 5812 S 1 0.4 0:13.23 artsd
    1 root 20 0 2844 1692 544 S 0 0.1 0:01.42 init
    2 root 15 -5 0 0 0 S 0 0.0 0:00.00 kthreadd

This was captured after around 20 seconds when I interrupted the copy (Sorry, no early could I do it. The machine was not that responsive at that stage). Interesting thing to note is that why are the KDE applications eating up so much of CPU cycles. I'm doing the copy from the KDE filemanager, Dolphin.

Also to point is that when I/O is run, kcryptd takes up a good amount of CPU cycles (around 20-25%), but I think that should be correct because encryption/decryption itself is expensive. What is most bothering is the degradation of the entire OS during such I/O.