Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Kernel 2.6.32 Released

Posted by CmdrTaco on from the download-compile-reboot-repeat dept.

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

9 of 195 comments (clear)

  1. Does it Fix XKCD 619? by sheepweevil · · Score: 5, Funny

    All of these features are cool and all, but does it solve the well-known XKCD 619 bug?

    1. Re:Does it Fix XKCD 619? by Anonymous Coward · · Score: 4, Funny

      http://imgur.com/73EAu - RESOLVED, FIXED quite a while now!

  2. Big speedups for media workstations.. by delire · · Score: 4, Informative
    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.

  3. Is this a hoax, or what? by Sockatume · · Score: 5, Funny

    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?
  4. People work on the "easy" problems by Fished · · Score: 5, Interesting

    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
  5. Re:does KSM mean the death of Xen? by 1s44c · · Score: 4, Informative

    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.

  6. Re:ATI support by Anonymous Coward · · Score: 5, Informative

    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.

  7. Re:Llacking in terminology. by Bert64 · · Score: 4, Interesting

    I have a system running a 2.6.32-rc6 kernel with KSM and the latest kvm (which includes support for this, but its turned off by default)... Because i run a number of virtual images that boot the same kernel and system libs (different apps ofcourse), it saved me over 1gb of memory on the host.

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  8. time saving makefile by inode_buddha · · Score: 5, Interesting

    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