Comment 162 for bug 131094

I was using a ICH4-M chipset and currently a ICH8-M system. The I/O wait is at 100% when, the problem occurs.
This issues occurs on my desktop machine with an AMD 790G chipset too. I know someone, who uses a VIA KT800 and is affected too by this bug. But as he uses his computer only for office work, it does not appear as often as on my machines.

At http://bugzilla.kernel.org/show_bug.cgi?id=7372 there are at least three different bugs. The initial bugs should be solved (see https://bugzilla.redhat.com/show_bug.cgi?id=444759).

The 64 bit problem, cannot cause the desktop responsiveness issue, because I have used a Pentium M, when I have switched from Feisty to Gutsy.

And it is right, that this is not a bug specific to Ubuntu, but Ubuntu seems to be most affected by the bug. The desktop responsiveness with Fedora 9 and 10 is much better on my machine.

I have done some research and tests. Here are some interesting results.

As the desktop performance in centos becomes "worse", when updating the from kernel-2.6.18-92.1.10.el5 to kernel-2.6.18-92.1.13.el5, I have checked the differences. One patch "linux-2.6-fs-dio-use-kzalloc-to-zero-out-struct-dio.patch" was applied to the Gusty kernel the first time. I know, that the patch should not have affected the performance.
I have unpatched the fs/direct-io.c file in my Hardy test installation (790G chipset) (kernel 2.6.24-22-generic) and made some tests.
Compared to the pachted kernel, I have >>mostly<< startup speedups of applications up to 10. The boot process takes 45 seconds instead of 60 seconds. During heavy write IOs and loadavg of 18, I could sometimes "use" even firefox (maximal 2-3 seconds of freezes). The start of gimp takes sometimes only 30 seconds instead of 140 seconds, but mostly. I have made these tests more than five times and used an equal process for testing the two kernels. Always these differences.
But when copying a file, instead of executing eight concurrent dd writing operation. Firefox freezes immediately and it takes about a minute to connect over ssh. Although there is a load avg of only 2. This should be the problem, which is caused by not fair scheduling between read and write access. It was described somewhere in the thread, but i cannot access the thread anymore.
https://fcp.surfsite.org/modules/newbb/viewtopic.php?viewmode=thread&topic_id=52598&forum=10&post_id=247938

The I tried to simulate a slower harddisk (ICH8-M), and installed hardy on a full encrypted disc. Which reduces the write speed to 40MB/s. The were no more differences between the patched and unpatched kernels. Both were unusable.

The bug is affected by different timings. As there must be an threshold of drive speed, at which the system switches from bad to unusable. That's must be the reason, why ubuntu kernels are more affected as the fedora onces.

This bug is annoying. Please help the kernel team to solve this bug.