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."

Llacking in terminology.

[c0l0]

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!

Big speedups for media workstations..

[delire]

This 'Per-backing-device writeback' is pretty significant. I'm sure the feature film and database industries will love it especially:

The new system has much better performance in several workloads: A benchmark with two processes doing streaming writes to a 32 GB file to 5 SATA drives pushed into a LVM stripe set, XFS was 40% faster, and Btrfs 26% faster. A sample ffsb workload that does random writes to files was found to be about 8% faster on a simple SATA drive during the benchmark phase. File layout is much smoother on the vmstat stats. A SSD based writeback test on XFS performs over 20% better as well, with the throughput being very stable around 1GB/sec, where pdflush only manages 750MB/sec and fluctuates wildly while doing so. Random buffered writes to many files behave a lot better as well, as does random mmap'ed writes. A streaming vs random writer benchmark went from a few MB/s to ~120 MB/s. In short, performance improves in many important workloads.

Re:ATI chipsets

[Anonymous Coward]

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/ [ubuntu.com]
Just fetch the .deb that fits your architecture, and install it via `sudo dpkg -i /path/to/your/downloaded/archive.deb`.

Re:Llacking in terminology.

[1s44c]

I'm not perfectly happy with the term "virtualization memory de-duplication".

The term is a little nonspecific. However KSM is truly wonderful and I look forward to saving a ton of physical memory over my KVM machines when the kvm/qemu userland tools catch up.

This is already in redhat's virtualization stuff.

Re:does KSM mean the death of Xen?

[1s44c]

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.

KMS

[shentino]

Kernel Mode Switching is great except for the fact that all 3 major video card vendors decided to nix VGA console support.

Re:ATI chipsets

[erko]

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)

Re:ATI support

[Anonymous Coward]

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.

Re:ATI chipsets

[RubberDuckie]

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.

Re:does KSM mean the death of Xen?

[Bert64]

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.

Re:ATI chipsets

[bcmm]

I've been using the RCs of this kernel, and the Radeon r600 support is already much faster and more stable than fglrx.

Re:People work on the "easy" problems

[bcmm]

You're missing the bit where Flash is closed-source and the people that want it to work properly can't make it happen, whereas the people who can make it work don't want it to happen.

Re:One file system to rule them all

[Dr.Dubious DDQ]

"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."

Getting slightly off-topic, but after the FAT patent-trolling recently this interests me.

I went and dug up the sadly-neglected udftools package and installed it. Sure enough, the following command (found with a bit of Googling) seems to produce a filesystem on my SD card that can be read from and written to just fine by Linux, Mac OSX (Leopard), and Vista at least:
mkudffs --media-type=hd --blocksize=512 /dev/sdc
(Obviously one should substitute the appropriate device there...) No partition table needed. I'm not sure if the "blocksize=512" is necessary, but it appeared that it might be.

The only real problems I see are the fact that udftools appears to have been abandoned half a decade ago, so there is no fsck tool[1], and that all those elderly Windows XP machines apparently can't write to this format without 3rd-party software.

Looks promising to me, if development on udftools is picked up by anyone (and in the meantime is definitely usable), so thanks for the tip...

[1] Well, udftools does include a "udffsck", but it quite literally does nothing - the source code is a stub that consists entirely of a single "void main()" function that returns 0 immediately. Mac OSX has a newfs_udf, but also appears to lack a way of repairing/validating the filesystem.

Re:KMS

[shentino]

Yes.

However, ATI, NVidia, and Intel have all three decided to deprecate the VGA text console if used with KMS enabled.

So if you use KMS with one of those cards, kiss text mode goodbye becasue the powers that be refuse to support it.

Re:time saving makefile

[gringer]

There's also a "make localyesconfig" that will be even more useful for me, particularly for removing the need for initrd. I can now do a "make localyesconfig", and not have to try to guess what particular combination of compiled-in options is required for the computer to start up, then add in the additional things as modules.