Linux Kernel 2.6.24 Released

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

Comments

Wow. Lots of stuff.

[MostAwesomeDude]

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.

Merge Window?

[AndGodSed]

"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:Merge Window?

[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?

[iMaple]

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.

Re:Merge Window?

[Aladrin]

Did you seriously just managed to misspell both words in 'News Bulletin'?

Re:Merge Window?

[Anonymous Coward]

DId you seriously just manage to screw up correcting someone else?

Re:Merge Window?

[arkhan_jg]

DId you deliberately screw up that correction of a correction? You did, didn't you.

Re:Merge Window?

[Dolda2000]

Did you deliberately screw up that correction of a correction of a correction? You did, didn't you?

Still no orinoco monitor mode

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

Yeah tick less is fine stuff

[emj]

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 just waking up 5 times per second makes the CPU pretty cool...

Re:tickless kernel support?

[MostAwesomeDude]

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.

more power save links

[emj]

I was going to post this on Thinkpad wiki on power consumpton, but sadly the page is not working atm..

I am really grateful for this release

[eclectro]

The weekend is almost here, and I am looking for something to do. I want to argue about the scheduler.

Re:I am really grateful for this release

[ajs318]

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:I am really grateful for this release

[nagora]

Arguments are down the hall.

No they aren't!

Re:I am really grateful for this release

[0xABADC0DA]

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.

Anti-Fragmentation?

[kripkenstein]

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, 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?

[Anonymous Coward]

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.

Re: Anti-Fragmentation?

[Dolda2000]

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 so saves both page table space by itself, but more importantly, it allows the CPU to cache the page table in much fewer TLB rows. If a 1 MB mapping can be cached in one TLB row, the CPU won't need to swap TLB entries back and forth from the physical page table. Even if the page table may be cached in the normal CPU memory cache, it would still result in far better bus performance.

Re:Mirror list

[TeknoHog]

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.

Re:wireless drivers

[Jack Malmostoso]

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

Catching up to Windows on power

[dpilot]

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.

But from a methodology viewpoint, does anyone understand the road Windows has trod, and how they have gotten to where they are? For instance, things like the tickless kernel are pretty fundamental. Is the Windows kernel tickless, or how do they get their power down if it isn't?

Re:Catching up to Windows on power

[JasterBobaMereel]

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:Catching up to Windows on power

[ThePhilips]

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.

Re:Catching up to Windows on power

[MostAwesomeDude]

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:tickless kernel support?

[Andy Dodd]

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:tickless kernel support?

[Daimanta]

Basically, it prevents the computer from being ticked off thus preventing a hostile robot takeover.

eCryptfs persistent files

[omnirealm]

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, eCryptfs now works pretty well on networked filesystems like NFS and CIFS.

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

Re:more power save links

[Nukenbar]

A lot of links don't work 'at the moment' when you post them on Slashdot!

working great here...

[FudRucker]

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:Next "stable" release?

[Randle_Revar]

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:Video drivers

[Randle_Revar]

And the DRM kernel stuff will be getting upgrades soon

http://www.linux-foundation.org/en/Linux_Weather_Forecast/hardware#The_TTM_memory_manager
http://www.x.org/wiki/ttm
http://wiki.x.org/wiki/DRI2