Slashdot Mirror
Linux Kernel 2.6.32 Released
diegocg writes "Linus Torvalds has officially released the version 2.6.32 of the Linux kernel. New features include virtualization memory de-duplication, a rewrite of the writeback code faster and more scalable, many important Btrfs improvements and speedups, ATI R600/R700 3D and KMS support and other graphic improvements, a CFQ low latency mode, tracing improvements including a 'perf timechart' tool that tries to be a better bootchart, soft limits in the memory controller, support for the S+Core architecture, support for Intel Moorestown and its new firmware interface, run-time power management support, and many other improvements and new drivers. See the full changelog for more details."
I'm not perfectly happy with the term "virtualization memory de-duplication". Linux 2.6.32 introduces what is called "KSM", an acronym that is not to be confused with "KMS (Kernel Mode Setting)" and expands to "Kernel Samepage Merging" (though other possibilities with similar meaning have already emerged). It does not target virtualization or hypervisors in general (and QEMU/KVM in particular) alone. KSM can help save memory for all workloads where many processes share a great lot of data in memory, as with KSM, you can just mark a region of memory as (potentially) shared between processes, and have redundant parts of that region collapse into a single one. KSM automagically branches out a distinct, exclusively modified copy if one of the processes sharing those pages decides to modify a certain part of the data on its own. From what I've seen until now, all that's needed to have an app benefit from KSM is a call to madvise(2) with some special magic, and you're good to go.
I really like how Linux is evolving in the 2.6 line. Now if LVM snapshot merging really makes it into 2.6.33, I'll be an even more happy gnu-penguin a few months down the road!
:%s/Open Source/Free Software/g
YTARY!
All of these features are cool and all, but does it solve the well-known XKCD 619 bug?
I'm glad to see Btrfs improving so rapidly. I hope popular distros start including support for it, but more importantly, start using it as the default filesystem.
It's time for the ext-based filesystems to die. They are a technology that was obsolete a decade ago.
ReiserFS was set to kill them off, but unfortunately found another victim first... JFS and XFS only work well in certain high-end niches. But Btrfs is much better as an all-around filesystem, which is why it has a chance to finally put an end to ext-based filesystems.
rewrite of the writeback code
So you didn't de-lace the interace or uncabulate the turboencabulator? I'm now about 85% convinced that the open source movement is just making shit up.
No kidding!!! What do you say at this point?
Like the strip, and it raises a valid point. The bottom line is that kernel development advances more quickly than user interface and applications for the same reason that physics advanced more quickly than say ... psychology. That is, because developing a faster kernel is a much easier problem than developing a fun, usable desktop environment. It's easier to write, easier to test, and easier to debug. People tend to gravitate towards problems that they think they can solve--and ignore the problems they don't understand or don't want to deal with.
Personally, I think that the best way forward for Linux on the desktop would be to take GNUstep to the next level. There's a LOT of code there already written, and with a bit more work you might be able to have source-level compatibility with Mac OS X--which would give you access to a bunch of commercial apps. And, most importantly, the ability of the OpenStep API to produce a world class desktop--best in the world in fact--is proven. After 10 years, I don't think that either KDE or GNOME have really done all that much for Linux on the desktop... it's time to try a different approach.
Of course, I'm just kibbitzing, not bringing code. So what right do I have to say anything?
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
No, as Ubuntu Releases are version-stable, and backport security fixes only (Firefox being the exception of that rule). You may install the kernel from the mainline kernel PPA though: http://kernel.ubuntu.com/~kernel-ppa/mainline/ .deb that fits your architecture, and install it via `sudo dpkg -i /path/to/your/downloaded/archive.deb`.
Just fetch the
If KSM puts the KVM module on par with Xen in terms of performance then I think the writing is on the wall for Xen's demise.
No. Not at all. KSM saves memory but hurts performance. It shares memory across virtual machines to save memory.
Xen can't share memory across virtual machines, it's just not put together like that.
Performance is about identical for KVM and XEN.
Kernel Mode Switching is great except for the fact that all 3 major video card vendors decided to nix VGA console support.
On the downside, I'm peeved that Btrfs is GPL licensed, which will prevent it from becoming "the one true filesystem" from here on out.
Well, ZFS itself has a GPL-non-compatible license, but that doesn't prevent it from being usable in Linux as an independent user-space process through FUSE.
The same approach could be imagined under non-GPL-compatible OS: have the GPL implementation as a standalone userspace daemon.
(Which is not a bad idea - give more freedom to upgrade)
Windows users will be stuck with NTFS
No matter what. Even if some kernel guru released a tri licensed LGPL/BSD/Proprietary perfect file system, Microsoft will still be using NTFS and promising WinFS soon for whatever the next version of Windows is.
They have a strong case of NIH-Syndrome.
None of them will be compatible, and FAT32 somehow remains the only viable option for removable media.)
For removable media, UDF could be a good candidate too. It's getting widespread availability, specially since Microsoft added support for writing on Vista and Win7.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
If you're ok with not-so-open drivers, nvidia 3D cards have worked for years. I am waiting for quality open source 3D linux drivers, but until then, at least 3D can and has worked reliably on linux. (the nvidia-settings tool is reasonable enough that you generally don't need to edit config files)
The 2D specs were released in September 2007. The 3D specs were released in January 2009. Drivers do not write themselves immediately just because the specs are out, it still takes some time. But it's getting there, and they won't go away like the closed drivers will, the moment the manufacturer feels it's no longer profitable to maintain them.
Linux 2.6.32 introduces what is called "KSM"
WHAT!? I know Linux users are pretty militant (myself among them), but to implement terrorism in the kernel?
Please tell me it's at least built as a *module* by default!
The Fedora team has backported the KMS and R600/700 improvements to FC12, which I've been running for a few weeks now. While it's better than nothing, 3d performance still has a way to go. The performance of my old Heretic II game is still unacceptably slow.
The ATI drivers usually took the sacrifice of a goat to get them to work, but their performance was far superior. Too bad ATI won't support recent releases of Fedora.
Instead of storing multiple copies of the same data in memory, it stores a single read-only copy and points the others to it. If you try to write to it, it traps, creates a new read/write instance which is exclusive to you and then points you at it...
Shared libraries work in much the same way. Shared libraries been implemented pretty securely for many years now.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Comment removed based on user account deletion
I'm very interested in the new make target. Specifically, "make localmodconfig". It seems that this new target will check your current .config, and also check whatever modules are currently loaded. It then creates a new config file which only builds the modules you are currently using. This could be a great time and space saving, as opposed to building everything and the kitchen sink as distros tend to do. It gives you a fairly easy and sane way to truly tweak your kernel to fit your box, or script it to fit a whole bunch of non-similar boxes.
C|N>K
I've been using the RCs of this kernel, and the Radeon r600 support is already much faster and more stable than fglrx.
# cat
Damn, my RAM is full of llamas.