Poor performance (unresponsive, pausing, stuttering etc.)

[gforum]

hey fitz, try the latest zen-sources, they got some nice new features and lots to do with scheduling... might help you in any way and form.
(more info on that in the gentoo forums)

gluck!

cheers.

[Fitzcarraldo]

Those Gentoo Forum threads I linked to in my first post in this thread have thrown up some more interesting information on this long-standing problem. One of the posts there particularly grabbed my attention:

Hope For Fixing Longstanding Linux I/O Wait Bug

The latest post in the Linux kernel Bugzilla report on this problem is dated only a couple of days ago, and it looks like the bug is getting some serious attention. Fingers crossed that it will be resolved soon.

[Fitzcarraldo]

Well, it seems that the Anticipatory Scheduler will not be included in the 2.6.33 kernel and onwards: 2.6.33 is Out! Say Good Bye to the Anticipatory Scheduler. This is a pity, as the standard Linux I/O Scheduler, the CFQ Scheduler, gives the worst performance for me with my Acer TravelMate 8215WLMi laptop, and I have been using the Anticipatory Scheduler since kernel 2.6.26 and it has done the job well up to the current kernel I'm using (2.6.32). Oh well, I am waiting for a new laptop to arrive that I ordered last week; I hope that the new hardware works better with the CFQ Scheduler.

[Fitzcarraldo]

Looks like some more work has been done on the long-standing CFS latency problems experienced by some:

More Patches To Improve Linux Desktop Responsiveness (Phoronix, August 26, 2010).

They are going to be merged into the 2.6.37 kernel, so I'm looking forward to seeing how it behaves when it's released.

[DontPanic]

Have you noticed any difference with the Sabayon 2.6.35 kernel.

The raise-the-bar-to-PAGEOUT_IO_SYNC-stalls patch seemed to make a difference for me.

[DontPanic]

OK, you inspired me.

I've made up a 2.6.35.4 linux-sabayon kernel that uses the 11 patch set refered to by Mathieu Desnoyers.

They applied cleanly, and I'm running an amd64 kernel with those patches now (no segfaults in dmesg yet )

I can't tell much on this computer. I've never really had latency problems on the desktop here.

I'm building the same kernel on my slower x86 machine now. I might be able to tell the difference on that machine.

[Fitzcarraldo]

You move fast. I haven't even had the chance to build the 2.6.35 kernel yet, let alone apply the new patches (I'm just back yesterday from my holiday, and still feeling lazy).

My performance problem was on my previous laptop (Acer TravelMate 8215WLMi). My new Core i7 laptop is, as one would expect, much snappier than the old dual core. Nevertheless I'm still interested in the long-standing latency issue apparently related to the CFS and/or CFQ, so I'll be very interested to see how you get on with the new patches. If I get a chance in the next week I'll build the 2.6.35 kernel with the patches too, and give it a whirl.

[DontPanic]

You haven't missed much by avoiding 2.6.35 so far.

Kernel.org is already on their 4th patch set for this kernel. There was a patch to address a security vulnerability. Then two patches to address the mess that was created by the fix for the vulnerability (as well as some other issues).

I've been getting segfaults all over the place at times. But that seems to have settled down now.

Now that things have settled down, you probably want to get a kernel under your hood that doesn't have the security vulnerability. This vulnerability affects nearly every kernel version.

[Fitzcarraldo]

Yes, I read about the major security vulnerability in the kernel on the Softpedia Web site the day before I went on holiday, and had read on the Phoronix Web site about the various "disasters" with the 2.6.35 kernel. Apparently the security flaw was in the kernel since the first release of the 2.6 kernel! So much for the schadenfreude of many Linux users when criticising Windows' security, eh?! I am definitely going to build a new kernel as soon as I get the chance.

[DontPanic]

I spoke too soon about having tested the 11 patch Efficios patch set.

I misunderstood the method for enabling the patch set once the kernel is built. I'm rebuilding my patched kernels now with CONFIG_DEBUG_FS=y so I can manually poke my kernel to engage the patches.