Sabayon Kernel 2.6.37 better than the other Kernels?[Solved]

[grimly64]

An observation. With 2.6.37, can transfer files to externel HDD, surf the web, run a youtube video, play a movie, and download files all at the same time with little system delays.

Every kernel after 2.6.37, if transferring files to an external HDD, really can not do anything until the transfer is done. CPU goes to 100% most of the time, while with kernel 2.6.37 it rarely gets that high. Forget about surfing the web, the delay, most likely cause the cpu is working so hard, is about impossible.

If newer kernels would not use up all the cpu, would use them, but they do and I fall back onto kernel 2.6.37 because of that.
FYI, have a Q6600 Quad Core overclocked to 3000 Mhz, so the processor is not the cause nor the 8 gig of memory.

What do you think the difference is between kernel 2.6.37 and every kernel since then?

[cl00t]

I cannot help with solving your problem but I have no such problems here with kernel 3.2.0 & have had no such problems with any sabayon kernels, maybe the problem is elsewhere?

[Stupot]

Dunno if this will really help you but: http://kernelnewbies.org/Linux_2_6_38

[Fitzcarraldo]

If you're referring to the infamous "patch that does wonders" (discussed in e.g. Magical Patch!! and The ~200 lines patch that does wonders? We have it), you've got a good memory, Stupot! That's a good call. grimly64 can see if there is a difference in performance if he disables the functionality by using one of the three methods mentioned in the post Re: Magical Patch!!.

[grimly64]

If I understand this correctly, I will apply changes to "commands in /etc/conf.d/local" from http://forum.sabayon.org/viewtopic.php?f=59&t=22330&p=125755#p125755 The Magic Patch to the newest kernel and see if in the newest kernel can do different functions (like transfer files, play a movie, surf the web) and get same performance as in kernel 2.6.37.

Latest Kernel I had installed was sys-kernel/linux-sabayon-3.2-r12.

Just to clarify this thread. Was stating an observation of how newer kernels since 2.6.37, have not been able to multi-task as well as 2.6.37. The only question really was.. why not?

How I came to this observation is this. Have a large video collection, was transferring 100g from one external HDD to another external HDD. With all Kernals after 2.6.37, like kernel 3.2, pretty much uses all the resources and can not do much else with the computer until the transfer is done. With Kernel 2.6.37, can still use the computer for whatever, surf the web, watch a movie. Would rather research stuff on the web while files are transferring versus not being able to do anything at all on computer.

[Fitzcarraldo]

The 'patch' is no longer a patch: it was incorporated into the kernel 2.6.38 (see the link that Stupot posted) and so has been active in all the SL kernels since then. So what you need to try is to disable its functionality in the latest SL kernel, to see if it makes any difference to the performance on your machine. And there are three ways of doing that, as mentioned in the post I linked to earlier, namely:

1. Edit the kernel config of the latest SL kernel version and change CONFIG_SCHED_AUTOGROUP=y to CONFIG_SCHED_AUTOGROUP=n and rebuild the kernel (see HOWTO: Upgrade kernel using genkernel).

OR

2. Add the kernel boot parameter "noautogroup" (without the quotes) to your kernel boot line in the file /boot/grub/grub.cfg (either by directly editing it or by editing /etc/default/grub and running grub-mkconfig -o /boot/grub/grub.cfg).

OR

3. Open a Konsole/Terminal window, log-in a root user and enter the command:

Code: Select all

echo 0 > /proc/sysctl/kernel/sched_autogroup_enabled

Option No. 3 is the least worth trying as it won't force existing tasks back to the root group. I.e. it is not a conclusive test of whether or not the functionality that was first incorporated into the kernel at version 2.6.38 is the cause of your problem. Personally, I'd edit /boot/grub/grub.cfg as mentioned in Option 2 above, as that is quick and easy to do and you can just reboot and see if there is any change in performance.

Option 1 survives a reboot. To revert to the original kernel you could either reinstall the kernel image using the Entropy package manager or reverse the edit and rebuild the kernel. Option 2 survives a reboot. To revert to the original situation you just need to edit /etc/grub/grub.cfg and delete the "noautogroup". Option 3 does not survive a reboot. You are back to the original situation after you reboot.

[grimly64]

Tried Option # 2. That works very well.

Transferred 60 gigs and while that was transferring, had a 720p Youtube video playing, a torrent downloading, played a video, and even downloaded through the terminal BleachBit and ran it. So although it occasionally got 100% on all four cpus it all ran very well.

Thanks for the help! Now I am not stuck using an older kernel.

As Col. John 'Hannibal' Smith from "The A-Team" says; "I love it when a plan comes together"

[Stupot]

Glad I could help. It is quite interesting though. I think this is the first case I recall where this patch caused problems.