Surely not a way to do performance testing, #2

Thanks to all the kind folks for commenting on my previous post . After a couple of people who managed to mildly experience some performance losses over my mentioned "experiment" one guy with another IBM/Lenovo PATA-to-SATA bridge based system managed to reproduce the issue. Is this a hardware related one? I'd like to kindly ask owners of such machines to make sure their Lenovo/IBM laptop model has the bridge and attempt my "experiment". If this is not Linux's fault then surely for people with warranty there should be a remedy. Now where is find for windows so I can "experiment" the same there...;)

Surely not a way to do performance testing, but still...

Back then, when I started using Linux based operating system (namely, RedHat, Mandrake to finally settle on Debian and then finally arriving at Ubuntu) I used to show off to my Windows using friends one o "features" at the time that was the major attraction GNU/Linux had for me. Rock solid, smooth multitasking that always kept the system responsive and usable.

A special case of that was that I showed them, how on heavy disk IO of the system, I can still have a responsive UI and use the desktop while their Windows desktop on the other hand , using the same exact hardware, running the same "benchmark" operation, started to lag on the desktop UI, have very jerky mouse movement performance and nearly choke to death.

Are those times over?

Recently, I revived this "experiment" using my ThinkPad T43p laptop with the following specs:

• PCI-E bus
• 1GB Ram
• 1.87GHz
  
• 60GB PATA disk, connected in what is know as a pata-to-sata bridge.

I am runnign latest feisty, but I could also reproduce this using edgy, and dapper on the same laptop configuration. I am using the open source ATI Xorg driver.

Now, what I have done (I urge you to try the same and let me know how that went for you) is make sure no running application are open after boot, open one gnome-terminal window, and there in a quick sequence I do:

find /
CTRL+SHIFT+T (open a new tab on the gnome-terminal)

And repeat this until you have 4 tabs with find running inside them. Now when I attempt this to open some more tabs (1-2) , the UI starts to lag, disk access becomes increasingly slow and the UI eventually becomes so unresponsive that even the mouse cursor refuses to obey the the mouse movements. Even when not displaying the tabs output (e.g. ALT+TAB to another window entering text) the performance loss doesn't go away, and even prevents me from easily entering text to this blog post. The most annoying part of this, is that ALT-TAB to switch another app becomes nearly impossible when the system is under this load (e.g. you can actually see UI redrawing etc as it happens) Something tells me this should not be the case...

Does anybody have an idea why this is caused? How can we possibly address this? In the beginning I thought using the -nolatency kernels could help, but this seems to have no effect on this. Any insight, comment or feedback on that are welcome.