Red Hat Enterprise Linux 6 (The H)

[Posted November 15, 2010 by ris]

The H has a review of RHEL 6. "Heaps of new features become apparent when comparing the RHEL 6 [2.6.32] kernel with the version 2.6.18 kernel of RHEL 5, although more than a few of them are already old hat in many other distributions. For instance, the Completely Fair Scheduler (CFS) highlighted by Red Hat has been part of the Linux kernel since version 2.6.23. The "tickless" kernel, which stops the timer interrupt from going off a hundred or a thousand times per second when a system is idle, is already well-tested. This trick reduces both the power consumption and the basic load of RHEL 6 systems that operate as virtualised guests, which frees up the host CPU for productive tasks."

Dynamic ticks on RHEL6

Posted Nov 16, 2010 0:57 UTC (Tue) by promotion-account (guest, #70778) [Link] (3 responses)

Funny that 'dynamic ticks' was implemented long-time ago by Mac OS X: "Similarly to several realtime OSs, Mac OS X uses one-shot timers to drive its timing and alarm events. These are hardware interrupts that are set to go off only for specific needs, rather than periodically. With this design, the OS maintains an ascending list of outstanding timers and sets a one-shot event to fire only when it is time to process the event at the head of the list; when this occurs, the head is poped, and a new one-shot event is set according to the new head. This design is motivated by various benefits, such as reduced power consumption in mobile devices, better alarm resolution, and less OS noise.

--Secretly Monopolizing the CPU Without Superuser Privileges, USENIX

Some developers from the kernel community claim Linux originality on this front; this is false.

Dynamic ticks on RHEL6

Posted Nov 16, 2010 1:50 UTC (Tue) by aliguori (subscriber, #30636) [Link] (2 responses)

FWIW, dynamic ticks were introduced way back in 2005. The 2.6.18 kernel that RHEL5.x is based was released in 2006 and dynticks weren't yet merged.

The first OS X release for Intel was in 2006 so the Linux kernel was already developing dynamic tick support long before OS X on Intel was known publicly.

Dynamic ticks on RHEL6

Posted Nov 16, 2010 2:47 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

I have been told (but do not have the capability to easily verify) that BeOS (development largely abandoned by 2000 or so) has dynamic ticks in this sense too. The BeOS clone named Haiku (kernel of which is derived from a hobby side project from an ex-BeOS developer as I understand it) does seem to have dynamic ticks from a cursory examination.

So this is not a novelty and probably wasn't at the turn of the century.

Dynamic ticks on RHEL6

Posted Nov 16, 2010 3:21 UTC (Tue) by drag (guest, #31333) [Link]

Dynamic ticks first shown up in the Ti OMAP port of Linux in 2004. It was based, in concept at least, on the the NO_IDLE_HZ patch for IBM's s390 and a Linux 2.4 patch for the Linux high resolution timers project from before that.

http://muru.com/linux/dyntick/

According to the USENIX article linked above OS X uses a different design similar to what people use in embedded OSes were your depending on a particular type of hardware interrupt to help you with your scheduling.

So I can't see how that is any sort of proof of 'Linux didn't invent dynamic ticks' when OS X does not use ticks at all.

Red Hat Enterprise Linux 6 (The H)

Posted Nov 16, 2010 4:25 UTC (Tue) by djzort (guest, #57189) [Link] (5 responses)

The gap between rhel5 and 6 was waaaaaay too long. And the pains of the age of RHEL5 are only maybe 12 months away. We're struggling to take rhel6 seriously, with its software already 2 years old and abandoned upstream in some cases (like perl 5.10).

Red Hat Enterprise Linux 6 (The H)

Posted Nov 16, 2010 4:41 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

Upstream often abandons recent releases quickly. This is part of the value of Red Hat to continue maintaining releases long after upstream abandons it.

Red Hat Enterprise Linux 6 (The H)

Posted Nov 16, 2010 6:15 UTC (Tue) by dowdle (subscriber, #659) [Link]

RHEL6 is basically based on Fedora 12 which was released only 1 year ago two days from now. I believe they've updated a few things since F12... like using 2.6.32 (with some backported stuff) rather than 2.6.31... so I'm not sure how it is 2 years old already.

Certainly no one is twisting your arm to use it.

Oldies goldies

Posted Nov 16, 2010 10:17 UTC (Tue) by eru (subscriber, #2753) [Link] (1 responses)

Depends on the users... The people to whom I regularly supply Linux binaries (in-house applications) are still mostly using RHEL4, so I have to build on that. I expect they start moving to this bleeding-edge RHEL6 maybe a year from now, but there will still be RHEL4 and RHEL5 systems for years afterwards.

Oldies goldies

Posted Nov 17, 2010 8:31 UTC (Wed) by niteeyes (guest, #6817) [Link]

I have to agree here. RHEL6 and its advances are just-in-time for my clients, who like to be just off the bleeding edge. These clients are more used to a Solaris-style release model, where stability and hardware support outweighs many other features. Users much closer to the bleeding edge are welcome to use Fedora, Ubuntu, Gentoo, or anything else.

Red Hat Enterprise Linux 6 (The H)

Posted Nov 17, 2010 12:43 UTC (Wed) by ovitters (guest, #27950) [Link]

If RHEL5 had a newer Python at the time of that release, I wouldn't have cared for RHEL6. Meaning: perfectly happy with RHEL5 and 6.

Red Hat Enterprise Linux 6 (The H)

Posted Nov 16, 2010 19:46 UTC (Tue) by RogerOdle (subscriber, #60791) [Link]

It is two years old? How long does it take to certify that an application stack as large as RHEL meets performance and security specifications. This can not happen overnight. You can always get the latest and greatest from Fedora but a production environment demands that you make every reasonable effort to assure that your hardware and software just work. Fedora does a commendable job of meeting that at a first order level but falls short of the requirements of a production environment. Linux needs RedHat and other corporations to do the deep level testing and debugging work that results in the hardened operating systems that corporations and governments need. This process often discovers bugs and inefficiencies that are hard to see by people trying to push the latest changes out. We should appreciate that RedHat supports both the short view (Fedora) and the long view (RHEL) of Linux. Each is important in its own way.