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

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.

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.

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.