Which Kernel Do People Use?

Home » CentOS » Which Kernel Do People Use?
CentOS 30 Comments

Hi all,

I’m doing a very informal and unscientific poll: which kernel do you use on your CentOS machines? Not which version of the CentOS kernel, but which repository. Here are some examples I can think of off the top of my head:

=

30 thoughts on - Which Kernel Do People Use?

  • Hello Keith,

    stock, latest available. But it doesn’t fully support my Dell Latitude E6530 hardware (webcam and some Dell Fn keys), so I’m interested in your poll!

    Regards,

  • I have a two CentOS systems.

    * A fanless VIA C6 system which provides network and telephony services
    on my home network. I use the stock kernel on this system.

    * A Thecus N5550 NAS. I use kernel-ml from ELRepo (along with a couple
    of hardware-specific modules for GPIO & LED setup). I use the “one-
    shot” LED triggers for drive activity LEDs, and they weren’t added
    until sometime after kernel 3.0.

  • Op 23-10-13 08:00, Ian Pilcher schreef:
    stock. on some laptops fn-keys do not work ——> that’s no reason to deflect from default I think on 3 laptops I have to use nomodeset sometimes I have to replace the wireless cards, don’t know if other kernels would remedy that.

    Greetings, J.

  • Kernel-lt on my “personal” server. There was some incompatibility between FreeBSD 9 and KVM with the stock kernel.

    Everything else is EL stock.

  • If you want SSD + MDRAID you need to use a 3.8+ kernel to have TRIM.

    The speed difference between the stock 2.6.32 -> 3.10 kernel with SSD +
    MDRAID is insane.

  • wwp wrote:

    I almost always use the latest stock kernel, with one memorable exception.

    I had a laptop which would not boot until I unplugged it and removed the battery. The reason was a faulty mouse driver, and the fix was to remove the mouse driver module prior to shutdown. The problem was that the mouse driver was compiled into the kernel. So I used the SRPM, changed the option to install the mouse driver as a module and recompiled. Following the directions on the CentOS wiki was pretty easy.

    c

  • I use the latest stock kernel and then use kmod packages from elrepo to update individual drivers as needed to provide improved hardware support or functionality.

    It’s the best of both worlds – I get the stability of the distro kernel with the additional hardware support/functionality I need.

  • I’m running CentOS-plus on my main workstation but multiple VMs run a custom kernel built from the CentOS SRPMS. I have two systems running CentOS with the upstream vanilla kernel, but these don’t get much use.

  • Going from HDD to SSD’s gave us better than a 95% reduction in query times for complex queries using PostgreSQL on otherwise identical hardware. I wouldn’t have believed it had I not seen it directly, for myself.

  • I use kernel-ml from elrepo for my Desktop due to hardware support as my hardware fails to even try to boot with the stock kernel as it used to just kernel-panic when I first got my new hardware, now on the most recent stock kernel just dies with USB errors (Prior to even attempting to start services etc.)

    kernel-ml works and boots just fine but it sure was fun and games getting CentOS installed and working…

    All of our servers run the stock CentOS kernel as all hardware appears to be supported and we need the stability more so than a desktop does.

    Kind Regards, Jake Shipton (JakeMS)
    GPG Key: 0xE3C31D8F
    GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F

  • Thanks to all for what was a surprisingly interesting thread! Here are my very informal and unscientific tallies. This isn’t actual systems, of course; it’s counting people’s responses, so my ~10 vanilla kernels count as one Stock in the tally below.

    Stock: 16
    CentOS Plus: 5
    ELRepo -ml: 3
    ELRepo unspecified: 2
    Custom build: 2
    ELRepo -lt: 1
    Stock + ELRepo kmods: 1
    Oracle: 1
    OpenVZ: 1

    No big surprise in the results; most people tend to stay with the stock kernel, but quite a few people use one of the others. I imagine that more people who didn’t respond would be more likely to be stock kernel users, so the numbers are probably a bit skewed towards the tinkerers and funky hardware or kernel feature requirements.

    People’s reasons for using a non-stock kernel were also not a huge surprise. I don’t recall anyone saying that they use a different kernel just to be recent; in the cases I remember everyone had a reasonably specific reason to use a non-stock kernel. That also makes sense here;
    it stands to reason that CentOS users want stability, and stray from the path only when stability is compromised by sticking with stock.

    Thanks all for responding!

    –keith

  • We’re all stock, all the way. Figure 30 servers configured like this, including dev/test and embedded servers. We’ll soon have a true
    “Disaster Recovery” setup with another 8 servers. Workstations run Fedora or Ubuntu.

    [bens@hal ~]$ rpm -qi kernel-2.6.32-358.18.1.el6.x86_64
    Name : kernel Relocations: (not relocatable)
    Version : 2.6.32 Vendor: CentOS
    Release : 358.18.1.el6 Build Date: Wed 28 Aug 2013
    06:28:07 PM UTC
    Install Date: Sat 07 Sep 2013 12:38:03 AM UTC Build Host:
    c6b10.bsys.dev.CentOS.org Group : System Environment/Kernel Source RPM:
    kernel-2.6.32-358.18.1.el6.src.rpm Size : 121423079 License: GPLv2
    Signature : RSA/SHA1, Wed 28 Aug 2013 07:02:55 PM UTC, Key ID
    0946fca2c105b9de Packager : CentOS BuildSystem < http://bugs.CentOS.org>
    URL :
    http://www.kernel.org/
    Summary : The Linux kernel Description :
    The kernel package contains the Linux kernel (vmlinuz), the core of any Linux operating system. The kernel handles the basic functions of the operating system: memory allocation, process allocation, device input and output, etc.

  • Lists wrote:

    interesting datapoint for HDD vs SSD, but what about kernel versions?
    When using SSDs, did you need to use 3.8+ kernels as suggested in the quoted post, or do you use stock?
    thanks

  • That’s great, but it’s not an answer to what has been asked. Have you tried SSD based software raid on stock kernel and on kernel-ml, have you noticed any big difference?

    I guess there should be some difference, software raid is not capable of TRIM in stock kernel, but I’m also not sure if a newer kernel is all that’s required, perhaps modifications to mdadm tool are also necessary.

    Lucian

  • I’ve taken some flack for being off-topic regards my comments on SSDs, though it would seem relevant to know that we’re using Stock CentOS
    kernel, and that we aren’t using trim because the performance increase was so much improved over spinning disks that we didn’t seem to need it. Our use case is a worst-case read/write scenario. The SSD partitions we use for the DB servers are mirrored software RAID1, which, to my understanding, makes the use of trim impossible.

    Where we’ve had performance problems we’ve always found something else to be the bottle neck, typically a poorly constructed query. (PostgreSQL
    really, REALLY hates left outer joins)

    It’s possible that we could eek out more performance with a suggested kernel update. If/when we do performance testing on that front, I’ll make it a point to submit my results.

  • in some tests I ran, also using PostgreSQL, a raid10 of 20 15000 rpm SAS2 hard drives performed about as fast as a raid0 of 4 SAS2 enterprise SSD’s at a very write intensive highly concurrent OLTP style (many small updates) workload. both storage arrays were behind a HP SmartArray controller that had a 2GB write cache (with supercap/flash backup)

    when I exercised the SSDs for a week continuously such that their full capacity had been written several times over, they slowed down 2 or 3 to
    1 from their original speed. at no point was the SSD array more than
    50% full.

  • Am 25.10.2013 um 13:47 schrieb Nux! :

    saying that – what about general usage of non-stock / higher-version kernels. There is a non trivial dependence between kernel and userspace tools. Are there really no pitfalls, running e.g. a kernel 3.11 on EL6 (as stated http://elrepo.org/tiki/kernel-lt)?

    Just curious.

LEAVE A COMMENT