Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Software Linux

Linux Kernel 2.6.24 Released 108

Posted by Soulskill from the new-toys dept.
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."
This discussion has been archived. No new comments can be posted.

Linux Kernel 2.6.24 Released More

Linux Kernel 2.6.24 Released

Comments Filter:

  • 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) 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...

      • more power save links (Score:3, Informative)

        by emj ( 15659 )
        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

        • Re: (Score:3, Insightful)

          by JasterBobaMereel ( 1102861 )
          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 ....

        • Re: (Score:2)

          by Andy Dodd ( 701 )
          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: (Score:1, Insightful)

          by Anonymous Coward
          Then you probably heard wrong. You might be confusing it with ACPI support - a standard which Windows does not implement correctly, which Microsoft give away defective tools for implementing (resulting in defective support for ACPI on many machines, particularly laptops), and which manufacturers support by testing against Windows only. It works in Windows only because hardware manufacturers make it work in Windows, but tends not to work so well in Linux.

          In all other respects, Linux is way ahead on power con
          • The original poster heard right, and you're spreading misinformation. Windows XP is way better at conserving battery power than Linux. Tools like powertop and tickless have been enabling great improvements in power consumption but it's still nowhere near that of XP.

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

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

                I doubt this is true. Do you know for a fact, for instance, that none of the other two major operating systems don't already have dynamic ticks? How many people on slashdot are familiar with the windows kernel? You don't have to work at microsoft to get these architectural details (windows architecture is detailed in a number of books, and university students often have access to wind

              • Re: (Score:3, Interesting)

                by MostAwesomeDude ( 980382 )
                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.

              • Re: (Score:1)

                by Ant P. ( 974313 )
                The xsession-errors file is doubly useless in that it deletes itself when X exits.

                The real worst offender would have to be Konqueror though, which calls sync() Every. Time. It. Uses. The. Cache.
                For example, opening a html file in it containing just the line "<meta http-equiv="Refresh" content="0">" will keep your hard disk light perpetually lit.

    • 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: (Score:1)

        by pmontra ( 738736 )
        I googled a little and found this article http://lwn.net/Articles/211505/ [lwn.net]. I'm not sure that this is all of the story, but it should be a good starting point for further investigations.

      • 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).
      • I am curious if any versions of Windows provide this feature. If not then chock one up for Linux...

      • Re: (Score:2)

        by Hatta ( 162192 )
        Why is memory fragmentation a problem? It's not like your RAM has to move a physical head to read non-contiguous blocks.

        • Re: (Score:2)

          by Azarael ( 896715 )
          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.

          • Re: (Score:2)

            by spitzak ( 4019 )
            malloc allocates pieces of the processes virtual address space to the program. All this fragmentation disappears when the program exits, so this is not exactly a problem with "the system being up for awhile". However similar problems exist in the kernel memory allocation and those problems do persist until the system is rebooted.

            As far as malloc goes, I don't believe fragmentation really slows it down, it has algorithims for immediately identifying a block of sufficient size, and does not do a search. It ma
        • Correct, but unlike your hard drive, RAM is fetched into cache for processing in "rows", and there is only room for so many rows. The more related stuff is together in RAM, the less "swapping" rows in/out of cache occurs. With multicore systems, this is even more important, as processors must synchronize to be sure they don't manipulate data cached by the other core... further dragging things down as more RAM access occurs.

          Just like the hard drive is orders-of-magnitude slower than RAM, RAM is orders-of-mag
        • 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

  • Merge Window? (Score:2, Interesting)

    by AndGodSed ( 968378 )
    "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?
  • keep up the good work !

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

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

          As far as I know the new mac80211 wireless framework supports injection for any driver that uses it. You need to be running a beta version of aircrack-ng to take advantage of it though.

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

    • Re: (Score:3, Funny)

      by Daimanta ( 1140543 )
      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.

    • You just made my morning!
      Let us also digress into a micro-kernel vs monolith-kernel discussion.

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

        by ajs318 ( 655362 ) <sd_resp2NO@SPAMearthshod.co.uk> on Friday January 25, 2008 @08:58AM (#22180600)

        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.
        • Don't forget to compare the amount of _stable_ releases of Linux kernels (anyone have a number?) versus the GNU Hurd (zero). Didn't HURD development start almost a decade before Linus started on his work?

          • Re: (Score:2)

            by dbIII ( 701233 )
            It was really about "we are a small team and we will do it all but you can join us if you can prove you are truly uber" to the linux "send patches and I'll use them if they look good". I just never got to feel like one of the hurd.

            The timing really meant that a lot of people thought they would not be welcome adding to the hurd by the time they got fast net access while linux was still new and welcoming.

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

    • Re: (Score:1)

      by mac1235 ( 962716 )
      Oh no, this abuse. Arguments are down the hall.
  • 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.

    • Re: (Score:2, Informative)

      by Jack Malmostoso ( 899729 )
      There you go:
      http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/net/wireless;h=45adf0a95539e8a0ca5fddbb720319a9b7b39978;hb=HEAD [kernel.org]
      If you want a suggestion on what to buy, support for Intel chipsets is very good. I have a 4965 device supported by iwlwifi and it works like a charm.

      • Re: (Score:2)

        by schon ( 31600 )

        If you want a suggestion on what to buy, support for Intel chipsets is very good.

        Unfortunately, unless you're an electronics engineer, purchasing a chipset doesn't do you very much good unless it's already on a card, and card manufacturers don't advertise which chipset is on a specific card (in fact, chipsets in many of the cheap cards get changed with other ones from batch to batch - I guess the cardboard boxes are more expensive to change than the electronics on the card.)

        I'd love to get a wireless card with an intel chipset, but try finding a card that says they use them.

        • Re: (Score:1)

          by Enleth ( 947766 )
          In the case of a laptop, that's easy. Intel makes the whole MiniPCI card and markets it with their brand. With a desktop, you can either try to find a working PCI card, or just... Well, buy a MiniPCI->PCI converter for $10 or so and you're done. That's what I did.

      • Re: (Score:2)

        by leoxx ( 992 )
        Does the 4965 driver support LEAP yet?
  • Does anyone have an idea when tuxonice will be re-merged? I know that most of the heavy lifting is done is userspace, but it would be nice if we didn't have constantly track down patches.

    LK

  • Tickless kernel now supports high res timers (Score:1, Informative)

    by Anonymous Coward
    In previous non-realtime Linux kernels the calls to nanosleep() or usleep() that were less than one tick (10 milliseconds) were rounded up to 10 milliseconds. This can be very frustrating when writing embedded software that needs responsive timers. Now the resoultion is down into the microsecond range with current CPUs and will scale down even further with faster CPUs.
  • When is the next "stable" release, a la 2.6.16? I got fed up with the earlier 2.6 kernels and have been sticking with 2.6.16 until there is another release in which the devs make another serious attempt at stability.

    • Re: (Score:2)

      by Hatta ( 162192 )
      It would be nice if you described the problems you've had with recent kernels. I haven't noticed any instability.
      • Random kernel lockups with a 9-way IDE software RAID on a 1.2ghz Athlon under 2.6.17 and 2.6.18 is the first thing that jumps to mind. Massive interrupt error counts when using more than one channel on Promise IDE controllers on the same.

        I haven't tried it on 2.6.>20 and I don't plan to until someone does like was done with 2.6.16 and declares a stable version that will continue to receive bug fixes but not destabilizing new features.

        I understand that there are some folks who find it immensely entertaini

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

    • Re: (Score:2)

      by WK2 ( 1072560 )
      That partly depends on what you want to do. I'm just a regular guy, and the kernels in Debian Stable and Debian Testing work for me. I don't know what to say if you're trying to write a device driver or something. But one of the things that distros are for is a stable Linux kernel.
      • Which is just a swell theory until you realize that most distros (I'm lookin' at you, Red Hat) do a lousy job of stabilizing the kernel for release. Even with one that does it well (debian) its still unhelpful if you happen to need to run several distros and several versions of each (as is not uncommon in larger deployments) and would like a single kernel that's reliable on all of them.

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

Slashdot Top Deals

We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated.

Close