To view parent comment, click here.
To read all comments associated with this story, please click here.
An even simpler way to reproduce the issue is to use dd.
dd if=/dev/urandom of=/somefile bs=1M count=10000 can cause an X11 GUI (KDE, GNOME, Xfce, etc) on Linux to slow down to a crawl until the dd is done. Doing the same with a USB drive makes it even more noticeable.
The same test on a non-Linux system will not affect X11, though.
I'm not sure where you're getting this...
I just ran in this command:
dd if=/dev/urandom of=test bs=1M count=10000
on Ubuntu 10.04 on a Core i3 530, which is relatively slow. I noticed no decrease in responsiveness whatsoever. I even tried playing an OpenGL game. The FPS dropped by a few frames, but it was not choppy or unresponsive at all.
Maybe it's just your particular system that has problems?
(Note: I'm not trying to say that there is a problem with X11. I'm saying that the problem doesn't exist, in Linux or X11.)
It is an official Linux kernel bug affecting 15% of x86_64 installting. It is not the scheduler, the kernel just fail to do it's job. Linus tried to solve it but failed, many other tried too.
My desktop is affected by the bug, my Laptop is not. It depend on the chipsset and some hardware parts, but is due to their drivers.





Member since:
2006-09-02
No, he is right. Compiling is OK, but just try to uncompress an 1G rar file or copy some files in the background and the GUI will come to a crawl. Not just the GUI, actually: CLI programs like vim are affected too. CFS is horrible for the desktop.
And I experience this both on my Core2Duo home computer and at my workplace on an 8-CPU beast, so the problem is definitely there.