The Kernel is the only thing in there that ISN'T from RedHat
This is wildly misleading. Almost everything Red Hat ships in Enterprise Linux is not from Red Hat. Projects like GCC, RPM package manager, Gnome, Glibc, KDE are all too big for Red Hat to develop on its own. The only things I can think of that are completely from Red Hat are layered products like Directory Server or projects where Red Hat has maintainership and majority contributions, like NetworkManager.
Having said that, I can't think of a kernel contribution report in recent years where Red Hat was not #1.
Apparently to call it a "new" kernel TFA feels they should have started entirely from scratch.
To call it a "new" kernel it has to be something less than nine months old.
"Fine tuning" could be anything from tweaking some compiler settings to actually patching things in the kernel.
They patched quite a few things, but at the same time thought it important to be as close to mainline as possible. Here's the lowdown from Chris Mason over at LWN:
One of the goals of this kernel was to stay as close to 2.6.32.stable as we could. The sources are here in git, they won't be rebased:
The main differences from mainline:
*) semtimedop optimizations. I posted these to the list a while ago, and Manfred took things in a less complex direction. He was waiting for me to fully benchmark the less complex version, but we ran out of time in the release cycle and had to focus on other things. Oracle hammers on the IPC lock, so these made a big difference, and now I finally have time to properly benchmark his approach against mine.
*) Small lock contention fixes
*) Receive packet steering
*) A large update to RDS (this is in a different package)
*) A patch to list msi irqs for each device in sysfs. A modified irqbalance uses this to keep irqs on numa local cpus.
There are other bits and pieces, but we resisted the urge to pile things in.
The solid state disk access number came on a huge machine, and the improvements came from getting rid a lock in the driver and enabling it for softirq affinity code without taking any of the request locks.
Over the next 12 months we'll be getting an update prepared to a new mainline version, and trying to hammer on upstream kernels as much as we can to reduce our patch count even more.
What is the next big problem?
You could try your hand at the other unsolved Millenium Prize Problems.
The world is coming to an end--save your buffers!