Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Linux Kernel 2.6.24 Released

Posted by Soulskill on Fri Jan 25, 2008 03:34 AM
from the new-toys dept.
Software Linux
LinuxFan writes "Linus Torvalds has released the 2.6.24 Linux Kernel, noting that he and most of the other key Linux developers will be flying to a conference in Australia for the next week. As the whole team will be down under while the kernel is being tested by the masses, Linus added, "Let's hope it's a good one". What's new in the latest release includes an optimized CFQ scheduler, numerous new wireless drivers, tickless kernel support for the x86-64 and PPC architectures, and much more. Time to download and start compiling."
+ -
story

Related Stories

Submission: 2.6.24 Linux Kernel Released by Anonymous Coward
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Linux Kernel 2.6.24 Released 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Wow. Lots of stuff. (Score:5, Interesting)

    by MostAwesomeDude (980382) on Friday January 25 2008, @03:42AM (#22179056) Homepage
    On one hand, things like the VM dirty writeback adjustments and default cpufreq frequency governors, as well as dynticks for more arches, are big performance improvements. On the other hand, they broke wireless packet injection patches for a lot of drivers... At any rate, I'll have to try this just to see if it really performs better. Things like laptop_mode which rely on optimized scheduling and writeback code should see improvements.

    • Yeah tick less is fine stuff (Score:5, Informative)

      by emj (15659) on Friday January 25 2008, @04:30AM (#22179270) Homepage Journal
      Reducing wakups on laptops is very interesting suff, I've seen some post on how muche better the NO_HZ is making things, e.g. Ross went from 164w/s to 5w/s [burtonini.com] just waking up 5 times per second makes the CPU pretty cool...
      • I was going to post this on Thinkpad wiki on power consumpton [thinkwiki.org], but sadly the page is not working atm..
      • From everything I've heard, Linux is still only catching up to Windows in terms of power consumption. It's fun because we hear all of the details, and until someone builds some nifty package, we script all of the dial-tweaks ourselves. Part of the fun is knowing the dials and what they do, but I guess that's not fun for everyone, some want it to just work, and we're getting there. As long as I can still see the dials, understand them, and tweak them, good automated default power management is good, too.

        B
        • What you do is you get the hardware manufacturers to write their device drivers to your specs so you can rely on devices going to sleep and waking up properly and reliably then you can write easily make the system consume very little power

          The you write the system so that it uses more memory than you have and so swaps to disk constantly so that it uses huge amounts of power when working and only saves any power when the whole system goes to sleep ....

        • Windows power management used to SUCK in early versions of XP. XP's support for SpeedStep on Pentium 4-M CPUs was abysmal, for example. The Windows 2000 SpeedStep app from Intel (which didn't work in XP) was lightyears ahead of what XP had built in. Back in 2001-2002, Linux could easily blow away a Windows machine in terms of power consumption. Since then XP has improved due to lots and lots of "behind the scenes" tweaks, and to some degree, hardware manufacturer cooperation.

          For example, one of the few

            • Re:Catching up to Windows on power (Score:5, Interesting)

              by ThePhilips (752041) on Friday January 25 2008, @05:19PM (#22187716) Homepage Journal

              It is sad reality the people keep mixing up technology and products.

              Linux (as kernel and piece of technology) is far ahead of most OSs in power management and especially in power saving.

              But. Take fresh Windows XP installation - it would give you decent up-time from single battery charge. Take Mac OS X - it would give you excellent up-time from single battery charge. Now take Linux's distro with X.Org/GNOME/KDE/etc - and it would eat any battery in under two hours.

              It is possible to optimize Linux to be extremely power efficient, yet lion share of applications written for PCs simply fail on portables.

              From recent example. I'm reading lots of PDF ebooks - under Mac OS. Trick is to scroll document to the end and then go back to place were you stopped: Mac OS would cache the file and hard drive will not wake up for the whole time you read thru the PDF. Linux? - Ubuntu/Kubuntu/SUSE/YellowDog were tried - hard drive is always spinning. Always. Non-stop. I stopped even trying to investigate what keeps it spinning - just went back to Mac OS. Because battery lasts under Linux for about 2 hours - while Mac OS on the aging iBook easily does 6 hours. But honestly, even if battery charge set aside, the noise produced by constantly spinning hard drive me slowly crazy.

              Conclusion: excellent power management of kernel != end-user application are designed with power efficiency in mind.

              P.S. Most common offenders are X.Org with its ~/.xsession-errors (as if end-users cared about all the cruft in there - developers simply do not look there at all) and syslogd which periodically (by default every 20 minutes) write marker into logs.

              • Go grab laptop-mode-tools (I guarantee it's available for your distro) and a kernel newer than 2.6.10, and then enjoy. Among other things, your hard drive will only spin up once every 10 minutes at most if you're not requesting reads or writes. It's possible to beat Windows in battery usage very easily -- Windows can't do things like power down the USB buses if there's nothing connected or requesting power, or sleep the CPU for 99% of its ticks.

    • Anti-Fragmentation? (Score:5, Insightful)

      by kripkenstein (913150) on Friday January 25 2008, @05:32AM (#22179500) Homepage
      The updates most interesting to me are the anti-fragmentation patches,

      Tests show that about 60-70% of physical memory can be allocated on a desktop after a few days uptime. In benchmarks and stress tests, it has been found that 80% of memory is available as contiguous blocks at the end of the test. To compare, a standard kernel was getting ~1% of memory as large pages on a desktop and about 8-12% of memory as large pages at the end of stress tests.
      Perhaps someone can clarify exactly what this means? Reading the beginning, it talked about 4K pages, device drivers, and such, so I assumed it would just be relevant to the internal workings of the kernel. However, the quote I pasted above seems to indicate it might impact desktop performance as well.

      I commonly see on my desktop, after several days uptime, that quite a lot of memory is being used (and I know how to ignore cache/buffers, as well as swapcache - that isn't the issue). Logging out and logging back in returns memory to reasonable levels (and the system becomes more responsive, but then I guess if I bought more memory I could accomplish that as well). Now, I've generally read that the problem was indeed memory fragmentation, e.g. here [gnome.org], but this would be internal fragmentation inside an app, and thus not relevant to the kernel, I believe? If someone can explain this issue I'd be grateful.

      • Re:Anti-Fragmentation? (Score:4, Informative)

        by Anonymous Coward on Friday January 25 2008, @09:01AM (#22180630)
        He's talking about how the memory blocks allocated to user programs are actually laid out in physical memory. Think of it like this: if we have programs A, B, C, and D using memory (and F for free), before the physical memory may have been allocated something like this:
        AAFBBFABCFCDBACDDBAF (not contiguous)

        And now more like this:
        AABBBAFFFCCCCDDFFFFF (free memory is in large contiguous chunks)

        This is not something that userspace programs will notice directly, but it does affect performance of the machine. Keeping free space and other areas contiguous allows for better caching performance and faster access.
      • It sounds like it's talking about memory management for external fragmentation. Here [lwn.net] is an article that looks like it is talking about those patches. Here [memorymanagement.org] is a site that seems to explain memory management pretty well. I could try explaining stuff myself but I'd probably miss some of the nuances (I'm no OS expert by any stretch).
      • Why is memory fragmentation a problem? It's not like your RAM has to move a physical head to read non-contiguous blocks.
        • After your system has been up for a while, the list of 'free memory' updated by malloc() and free() gets fairly fragmented into odd sizes, that are spread out (especially if you aren't allocating in sizes near powers of 2). The more fragmented this list gets, the longer it takes for malloc to locate a block of memory that fits the size that you want. If I understand correctly, this change should make it possible to keep the free list more organized.
        • I'm not sure exactly how this works, so I can't go into all too nitty-gritty details, but basically, it's like this.

          x86 CPUs (and probably amd64 as well) allow the kernel to choose between two page sizes: The usual 4 kB ones and a much larger size (I think it's 1 MB or so). The performance issue is that if the kernel can keep the physical RAM pages that back a large contiguous virtual mapping contiguous in physical RAM, it can use one of the jumbo pages instead of potentially hundreds of 4 kB pages. Doing

  • "Since I already had two kernel developers asking about the merge window and whether people (including me) traveling will impact it, the plan right now is to keep the impact pretty minimal. So yes, it will probably extend the window from the regular two weeks, but *hopefully* not by more than a few days."

    Now THERE's confidence for you. Great news.

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      I'm just wondering, should a core group be traveling together? What will the impact be if that plane impacts the ground?

      • Re:Merge Window? (Score:5, Funny)

        by iMaple (769378) * on Friday January 25 2008, @04:28AM (#22179258)
        There is a chance that some stupid airline CEO decided that their planes use The Evil Darklord's software for navigation. Of course we all know that noone would NEVER code a special condition in the software which says

        if(passenger_list.contains(entire_linux_kernel_team){
              flyinto(mount_everest);
              output_evil_voice("muhahahhaa");
        }

        On the other hand, there is nothing to worry about. This feature probably was shelved and is definitely going to be in the *next* version of the OS.

  • Still no orinoco monitor mode (Score:2, Interesting)

    by Anonymous Coward
    The orinoco wireless drivers have supported monitor mode since 2004. Still not in the kernel today. Do any of the BSDs support monitor mode yet on this incredibly well documented chipset? I'll migrate if the answer's yes.
    • ---The orinoco wireless drivers have supported monitor mode since 2004. Still not in the kernel today. Do any of the BSDs support monitor mode yet on this incredibly well documented chipset? I'll migrate if the answer's yes.

      Good point. Would anybody more enlightened than I explain why the good orinoco drivers arent accepted in the kernel?

      Evidently asking questions like this is flamebait... but why is this so WRT the kernel?
      • What I would like to know, personally, is why the aircrack-ng patches for injection (http://patches.aircrack-ng.org/) are still out-of-tree.
        • I can see why with aircrack...

          Look at their release dates and patch revisions... none current. Kernel guys like seeing constant and timely patches. Community members who slack off are considered bad and all..

          But I guess the wireless guys dont like these addons... Good for them, bad for us.
  • Can anyone explain to me what "tickless kernel support" is?

    • Re:tickless kernel support? (Score:5, Informative)

      by MostAwesomeDude (980382) on Friday January 25 2008, @04:32AM (#22179274) Homepage

      Can anyone explain to me what "tickless kernel support" is?
      Sure. Basically, instead of having a regular tick in the kernel every handful of cycles to process interrupts and timers, processes are given long, dynamic timers with arbitrary lengths, which means that if an app wants to sleep for a relatively long period, it gets to sleep and not wake up the CPU, so the CPU sleeps longer and a lot of power is saved.
      • Does this also mean that an app can also sleep for a very short period? Normally a sleep function is limited by the granularity of the kernel ticks. Will this make sleeping for, say, 1ms more accurate and reliable?

        • Re: (Score:3, Interesting)

          by Andy Dodd (701)
          There is another patch that adds high resolution timers to Linux. (Actually, another component of a gigantic patchset that has been rapidly getting mainlined over the past few kernel releases.)

          I think CONFIG_HRTIMERS is already an option (may not default to on though). If it isn't, go find the RT_PREEMPT patchset. That includes (or if HRTIMERS is in the kernel, included) HRTIMERS, it's also where the NO_HZ option came from.
    • Basically, it prevents the computer from being ticked off thus preventing a hostile robot takeover.
  • It's always a nice read in the morning, that you don't need module-assistant anymore.

    (rt61 Wireless)

  • I am really grateful for this release (Score:5, Funny)

    by eclectro (227083) on Friday January 25 2008, @05:13AM (#22179416)
    The weekend is almost here, and I am looking for something to do. I want to argue about the scheduler.
    • would you believe i JUST upgraded to 2.6.23-r3 on Tuesday? I'm a kernel holdout, but hey, at least its better than the people who have been holding out to upgrade from 2.4.xx!!! Yea, the only reason I had to upgrade too was frickin gentoo dependency, I think because of KDE-base, whatever....

      • Let us also digress into a micro-kernel vs monolith-kernel discussion.
        Oh, that's an easy one. With a microkernel, you put up fences where they look pretty. With a monolithic kernel and loadable modules, you put up fences where as little stuff as possible has to traverse them. Ting! Next, please.

        • Re: (Score:3, Interesting)

          by 0xABADC0DA (867955)
          With a typesafe kernel like monotone or jxos everybody has a personal force field bubble around them that nothing crosses, and they just point at stuff outside their bubbles. Also, there are no laws because the force fields keep everybody perfectly safe all the time.
  • Could someone provide a quick summary of the wireless drivers that are now in the kernel as I don't know the chipset names for them and one of the sites appears to be /.ed.

  • eCryptfs persistent files (Score:4, Informative)

    by omnirealm (244599) on Friday January 25 2008, @09:24AM (#22180926) Homepage
    In 2.6.24, eCryptfs overhauled its I/O mechanism with the lower filesystem (check out fs/ecryptfs/read_write.c). It used to directly manipulate the lower inode address mappings, which caused problems with certain filesystems like NFS (they like to be the only filesystems directly locking, reading, and writing their own address mappings). Now it opens a persistent lower file for each and every stacked inode and uses that for all I/O with the lower filesystem. This significantly decreases the complexity of the execution path for reading and writing the lower data. Together with this patch [sourceforge.net], eCryptfs now works pretty well on networked filesystems like NFS and CIFS.

    There is another patch to provide HMAC integrity enforcement [sourceforge.net], and the kernel GIT tree for eCryptfs has a branch indicating that filename encryption is being worked on.

  • working great here... (Score:3, Informative)

    by FudRucker (866063) on Friday January 25 2008, @01:36PM (#22184612)
    i build as much as possible the only required support for my hardware specifics as modules except for ext3 filesystem support (built in to the kernel itself) thus making an initrd unnecessary, my kernel is nice & light, highly responsive and boots in just about 10 seconds, and the kernel is only 1.1 megs in size & /lib/modules/2.6.24 is 11 megs...

    • Re: (Score:3, Insightful)

      by TeknoHog (164938)
      Is there an active and/or "official" Bittorrent site for Linux kernels? The local mirrors take some time to update, so global torrents would make more sense. Besides, people who download kernel sources are usually the kind that appreciate the benefits of BT and know how to use it.
    • It would be nice if you described the problems you've had with recent kernels. I haven't noticed any instability.

    • Re: (Score:3, Informative)

      by Randle_Revar (229304) *
      I haven't seen stability problems in 2.6 for a long time. Lately I have been using the 2.6.24 (pre-release) kernel from Ubuntu Hardy (I'm on Debian Sid), and I haven't had any trouble with the kernel. X.org and Mozilla nightly problems, sure. But no kernel problems.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.