# What tells you that you should upgrade your kernel ?

## aCOSwt

Supposing that all your system's hardware is fully and perfectly driven and you get a perfectly functional system, what will then makes you decide to upgrade your kernel ?

Could those of you who answered one of the results of benchmarks options provide some details about these benchmarks, the capabilities they are specifically following and the kernel version they are currently running.

I am curious about this because I scrupulously followed all portage's stable versions of gentoo-sources from 2.6.29 up to 2.6.38, taking great care of each config option and then decided to rely on Sysbench --thread and --mutex, Kolivas' Interbench and miscellaneous home-made benchmarks because I found that they highlight the performances which matter to me.

The result is that I am still sticking to 2.6.38 since I found all > 2.6.38 kernels up to 3.2 included significantly less performing.

Would'nt it had been for the sole sake of a particular driver included in the kernel from 2.6.37, I would even have stayed on 2.6.32 that I personally found the best linux version ever.

The problem puzzling me is that new releases of system packages forbid an always increasing number of ancient kernel versions, 2.6.34 will be reached with new udevs... so... my 2.6.38 will in a near future be condemned to obsolescence. (If not already)

Am I alone ?

----------

## kernelOfTruth

from my personal experience 2.6.34 was the best performing kernel to date (afaik there were no issues while transferring lots of data via rsync and even working in parallel - no stuttering, interruptions, etc.), my architecture is ~amd64

I'd stayed with my heavy-patched 2.6.37+ kernel if there hasn't been issues with alsa not working after resuming from suspend-to-ram/hibernate

right now the most important reasons I'm upgrading are:

1) graphics drivers performance/features, stability improvements, data integrity issues resolved, etc.

2) new exciting features that I'd like to try out

3) security fixes - if those are critical I'll of course update asap

----------

## Jaglover

New features.

----------

## asturm

I voted 'Fun / interest in testing new versions' because it comes closest to it. But actually, I'm constantly testing out latest graphics branch because there's an external resolution detection problem that's bugging me since 2.6.32 and I am seeking cure since then. I'm following the bugzilla entry and consequently not emerging gentoo kernels but git pulling from danvet/drm-intel-next-queued. --> git diffstat tells me  :Very Happy: 

----------

## aCOSwt

Thank you all for contributing.

 *kernelOfTruth wrote:*   

> 1) graphics drivers performance/features, stability improvements, data integrity issues resolved

 

How do you tell that these improvements are actually efficient, I mean that your typical workload actually benefits from these improvements ?

@genstorm : I remember that you wrote in some thread around that you had noticed that 3.0 and 3.1 kernels had a greater latency than their ancestors.

I came to a similar conclusion but cannot find anything on the net confirming it.

How did you notice that, do you believe that it could be because of the implementation of the control groups ?

----------

## kernelOfTruth

I'm using lots of multimedia stuff on a daily basis (youtube, videos, etc.) and a composited desktop (with compiz-fusion 0.8.8 ) to oftentimes invert programs to notice details better in graphics or when reading long texts to putting less strain on the eyes

afaik there were some speed improvements some releases ago with the radeon driver (I've an evergreen card), loading the module with PCIe 2.0 support also helped noticably (or it's just imagination - whatever)

with 3.5 there should be some more gains (http://phoronix.com/forums/showthread.php?71406-Linux-3-5-Can-Massively-Boost-AMD-Radeon-Graphics)

for that kind of stuff I take a look at lkml, kernelnewbies and phoronix

the desktop can't be smooth and fluid enough for me  :Wink: 

----------

## asturm

 *aCOSwt wrote:*   

> @genstorm : I remember that you wrote in some thread around that you had noticed that 3.0 and 3.1 kernels had a greater latency than their ancestors.
> 
> I came to a similar conclusion but cannot find anything on the net confirming it.
> 
> How did you notice that, do you believe that it could be because of the implementation of the control groups ?

 

Hmm I can't remember. I think I said something like that back in the BFS days of mine. I don't use that anymore despite some (felt) responsiveness increase, because I didn't appreciate the scrambled sound at high load. These days I either have adapted to some bigger latency or it has gone, but CGROUPS I have enabled only recently because of some package depending on it. Anyway, much of a latency that could be felt came from laggy KDE and crappy Intel drivers, and both have seen improvements there lately.

----------

## Hypnos

Two main reasons:

1) Important bug fixes (e.g., security)

2) Ebuild is no longer in Portage (i.e., no longer supported by upstream or Gentoo devs)

----------

## xming

http://kernel.org/ tells me to upgrade  :Very Happy: 

----------

## Gaqua77

I just check it upon http://kernel.org/ it governs my system for a while & let me know that i need to upgrade or not.

----------

## djdunn

i upgrade when Linus says its stable.

----------

## Catanduva

 *djdunn wrote:*   

> i upgrade when Linus says its stable.

 

----------

## Randy Andy

I also voted for Fun / interest in testing new versions, but I'm also often interested in new features or need new driver support for new actual accessory hardware.

I read regular the german kernel.log of the heise magazine or the changelog of kernel.org and then I'm interested in testing new features or improvements regarding driver support or performance, or to get rid of proprietary firmware to support wlan chipsets, cause it's now built into the kernel e.g. which could make things easier to get work.

Some others came to mind, like BKL (Big kernel lock), or cgroups and later the "wonderpatch" which makes the desktop more responsive while compiling with lots of parallel jobs.

Support for a new Afatech DVB-T USB-Stick gets late into kernel, also support for my Ortek PKB-1700/WKB-2000/Skycable wireless keyboard and mouse trackpad (HID_ORTEK), both from Pearl onlineshop.

Especially the better responsiveness with wonderpatch was great, when i had to recover a very defective USB-harddrive with testdisk which lasts about 18 hours.

Without the patch the deskop feels like frozen, mouse cursor movement takes up to minutes of delay.

Kernel based modesetting, driver support which changes from staging into dircect support.

GPT-Support, for using gpt-partions bigger than 2TB in one partion. Actually I'm using 3x 3TB hard drives in this constellation.

Booting from those hard drives with the root=PARTUUID kernel command line, without using a initrd or the regular used UUID like in this example here:

```

kernel /boot/kernel-x86_64-3.0.0-gentoo vga=791 root=PARTUUID=29884E5A-69FF-42E8-AB7B-0DEB95FB6EA9 
```

see also these german thread, for those who are interested in https://forums.gentoo.org/viewtopic-t-882303-highlight-uuid.html

UEFI Boot support, for those who need (i hate it and hopefully never need it, but it came to mind)

Enough for now, but I'm sure the list could be longer the longer I thinking about it....

Regards, Andy.

----------

## ppurka

Other.

Ran 2.6.38 for more than a year. Decided to upgrade to 3.2 later hoping for better in-kernel wireless support for my chipset (bcm4313 - but the support in 3.2 didn't turn out to be so good after all). Later upgraded to 3.3 to address slowdowns (a.k.a. the infamous amd64 slowdown thread in the amd64 forums). Now, I have moved to the latest ck-sources in the tree because it seems BFS handles disk accesses much better than CFS.

EDIT: 2.6.38 was really the best experience for me. Everything worked, tuxonice, suspend, ... only the wireless was flaky. Since the move to 3.x series I don't have hibernate (the in-kernel one is a joke), wireless is so-so, and there are massive slowdowns on disk access with the default CFS.  :Sad: 

----------

## depontius

I maintain about a half-dozen Gentoo systems, and the policies vary.  My "play" system runs the latest ~amd64 gentoo-sources, about as soon as it shows up.  My other systems basically run stable, and I upgrade the kernel when I get around to it.

There have been several times in the past when I've been after some specific feature, and gone for a kernel version just to get that feature.  I've also applied a few scheduler patches in the past, and for a while I had to run out-of-tree hvr-1600 drivers.

----------

## <3

 *Hypnos wrote:*   

> Two main reasons:
> 
> 1) Important bug fixes (e.g., security)
> 
> 2) Ebuild is no longer in Portage (i.e., no longer supported by upstream or Gentoo devs)

 same here

----------

## John R. Graham

Moved from Gentoo Chat to Kernel & Hardware. Topic is about kernel maintenance, so it fits better here.

- John

----------

