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

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 [burtonini.com] 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 [thinkwiki.org], but sadly the page is not working atm..

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

Tickless kernel now supports high res timers

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

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

[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 [linux-foundation.org]
http://www.x.org/wiki/ttm [x.org]
http://wiki.x.org/wiki/DRI2 [x.org]

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.