Slashdot Log In
Linux Kernel 2.6.21 Released
Posted by
Zonk
on Thu Apr 26, 2007 03:36 PM
from the a-long-awaited-penguin dept.
from the a-long-awaited-penguin dept.
diegocgteleline.es writes "Linus Torvalds has released Linux 2.6.21 after months of development. This release improves the virtualization with VMI, a paravirtualization interface that will be used by Vmware. KVM does get initial paravirtualization support along with live migration and host suspend/resume support. 2.6.21 also gets a tickless idle loop mechanism called 'Dynticks', built in top of 'clockevents', another feature that unifies the timer handling and brings true high-resolution timers. Other features are: bigger kernel parameter-line, support for the PA SEMI PWRficient CPU and for the Cell-based 'celleb' Toshiba architecture, NFS IPv6 support, IPv4 IPv6 IPSEC tunneling, UFS2 write, kprobes for PPC32, kexec and oprofile for ARM, public key encryption for ecryptfs, Fcrypt and Camilla cipher algorithms, NAT port randomization, audit lockdown mode, some new drivers and many other small improvements."
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.
Full
Abbreviated
Hidden
Loading... please wait.
Damnit! (Score:5, Funny)
Meh (Score:3, Informative)
Re:Meh (Score:4, Interesting)
P.S. i never use reiserfs so i can not say if this works with reiserfs or not...
Parent
Re:Meh (Score:4, Interesting)
Its not just the file system you need, its the ability to spin the drive containing said file system too
The initrd does many more things than load drivers. What if you have an AoE based storage network with many disk-less stations needing to use an OCFS2 single system image? Initrd's can do neat things besides loading modules, have a look at linuxrc. You can bring network adapters to an up/link state, negotiate iscsi targets, download a boot config from a resource controller, all kinds of goodies. Complex networks need to do lots of things before pivot_root gets called, and we need complex networks.
piix hasn't been 'quite right' since 2.6.16.29 on most of the legacy servers using PATA (IDE) I still have up and working, many of us have been having a difficult time with it. But progress is progress, and this is good progress so I guess my move to all SAS will be sooner than later.
Parent
Re:Meh (Score:4, Informative)
IIRC after 2.6.17 the SATA stuff changed quite a bit (it changed from the old SCSI based stuff, to libata), and requires turning the new options on.
RegardselFarto
Parent
Re: (Score:3, Interesting)
I also notice the new feisty to be much faster, but when under load, desktop slows down considerably. On edgy, however hard you loaded the machine, there was always the extra power for sth else if you wanted.
Feisty looks feels like a windows machin
Re: (Score:3, Interesting)
This problem needs to go to lkml, and cc Andrew.
KVM management? (Score:3, Insightful)
Re: (Score:3, Informative)
Tickless only for x86 now, still good news (Score:5, Interesting)
I can't wait for it to mature on PPC, MIPS, and x86_64! Right now it's 32-bit x86 only.
Re:Tickless only for x86 now, still good news (Score:5, Informative)
Most kernels use a periodic system timer tick to do various housekeeping chores, like rescheduling tasks, sending packets, flushing files from the cache, etc. Usually this occurs at some periodic rate, i.e. every 1-10ms for Linux and every 10-15ms for Windows (according to this article [microsoft.com].
This is a bit wasteful of CPU resources, since the kernel might not need to do anything for quite a while, or it might want a high resolution timer with higher accuracy than normal system timer. For example, when the system is idle, the CPU still must wake up and process a timer interrupt for every timer tick, and if it's set to 1ms there are 1000 interrupts per second.
A tickless kernel instead only schedules the next tick for when it is needed, so if the system is idle and nothing needs to happen for 50ms, then the next tick will be scheduled 50ms later. On the other hand, if a timer needs to go off in 750 microseconds, the kernel can schedule the next interrupt to go off then, giving much higher accuracy.
Parent
Re: (Score:3, Informative)
That's nice and all... (Score:4, Funny)
Re:That's nice and all... (Score:5, Funny)
(Damn, finally there's an answer for this!)
Parent
Another solution to a timeless problem! (Score:5, Funny)
The list of changes can be found... (Score:5, Informative)
Re:Hotplug CPU support! (Score:5, Funny)
Parent
Sooner or later... (Score:3, Funny)
Re:Sooner or later... (Score:4, Interesting)
Yeah, the absurdly long kernel command lines in Linux really bug me. It's a symptom of the suckiness that is the PC BIOS, so I'm not really blaming the Linux people, but there are better solutions and have been for years. The FreeBSD loader [freebsd.org], for instance, is capable of loading the kernel and any modules required to bootstrap the system, reading configuration files, and running Forth (!) scripts. Such a loader would completely eliminate the need for initrds on nearly all systems[1] without sacrificing any power. You could also emulate Openboot or EFI - or more realistically a subset of them - using the PC BIOS to prepare for the future.
[1] initrd is a really awesome feature and it shouldn't go away. But it's massive overkill the way it's typically used, which is to load modules required to mount the root filesystem.
Parent
Re: (Score:3, Funny)
you forgot the
type=feline_supplement,id=25
Mactel MBP C2D (Score:4, Interesting)
Next up is to get ATI to actually support any power saving features in fglrx on the MBP C2D and give the mAdWiFi [madwifi.org] guys more time to work out the features on the Atheros AR5008.
OSX, right now, still has a significant advantage in keeping heat and power consumption down. Even though, I imagine some will testify that even OSX is having a hard time with it...
Here's to testing out 2.6.21 tonight
Re: (Score:3, Informative)
The MacBook was $1300 and features DVD RW, firewire, USB, bluetooth, wifi, a video camera, audio (record and play), a 3d graphics card and a 150 minute battery (for the way I use it). The coolest features are the little things that Apple did right: the magnetic power cord, the simple, sturdy case, the pulsing standby indicator, etc. I install the GNU bits that I need, but most of
Cool, but... (Score:3, Insightful)
Re:Cool, but... (Score:5, Insightful)
Considering that slashdot was (note the past tense) first and foremost a Linux/all things geeky site, I'd say this article is very slashdot-worthy. Not to mention that we get a fawning mac fan boy article every time Steve Jobs so much as farts. At least the Apple section can be turned off. Wish I could do the same with Microsoft and Windows articles.
Parent
eCryptfs public key (Score:5, Interesting)
In other news, eCryptfs has recently been given the go-ahead for inclusion into Fedora:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi
In the meantime, you can grab all the userspace stuff from the eCryptfs SourceForge site:
http://ecryptfs.sourceforge.net/ [sourceforge.net]
Re:Bloat? (Score:5, Insightful)
No, most distros are going to include a kernel with the kitchen sink compiled as modules, taking up a few megabytes on the hard drive, but never loaded.
Parent
Re:Bloat? (Score:4, Insightful)
And, of course, there's many parts that can not be made into modules at all, but have to be part of the kernel. And that makes a HUGE difference.
Is the difference really that big? Well, the machine I'm currently on has a bzipped kernel that's around 1.5 MB in size plus a 820 kB map. The alternative boot to a commercial distro (no name, no shame) has a bzipped kernel that's around 2.1 MB, plus a 2.3 MB initrd, plus a 1.2 MB System map.
The difference might not be staggering, but it's there, and the kernel is growing with each revision. Here's how the System.map has grown for the last few revision on this laptop, with no new options added:
-rw-r--r-- 1 root root 754620 Nov 30 18:32 System.map-2.6.17-gentoo-r8
-rw-r--r-- 1 root root 768275 Dec 28 15:57 System.map-2.6.18-gentoo-r6
-rw-r--r-- 1 root root 809157 Mar 26 04:28 System.map-2.6.19-gentoo-r5
-rw-r--r-- 1 root root 839371 Apr 25 22:45 System.map-2.6.20-gentoo-r6
That's an 11% increase without adding anything. Similar for the kernel itself (although that's harder to compare directly, due to the bzip2 compression). While not alarming, it's a trend towards feeping creaturitis that I think bears watching.
Parent
Re: (Score:3, Insightful)
Re:Bloat? (Score:4, Insightful)
Not to mention that people who are using Linux for embedded work can still rip out a ton of stuff. You can completely omit module support and all sorts of things that contribute to so-called "bloat." The kernel is still and always has been very flexible about compiling in features, and all the code's there to mess with...
Small, fast, full of features; pick two. I think.
Parent
Re: (Score:3, Informative)
Linux hibernate support (Score:3, Informative)
Re:Bloat? (Score:5, Insightful)
Most distros compile everything as modules, which generally keeps the overall size of the kernel down. Sure, bzImage grows over time (not just because of new features, but typically new patches == more lines of code), but not significantly from release to release.
Most "non-uber-geek" users don't care what's in their kernel, and if they did, they'd learn to compile it themselves. Compiling kernels has gotten easier over the years. Chances are, if you care enough about how your kernel is compiled, you'll have the skills needed to do it yourself.
Parent
Re: (Score:3, Funny)
Plus, I don't find it THAT hard to configure the new kernels but I take my distro's config file and remove anything I know I don't need rather than starting with a blank-slate config and THEN trying t
Re: (Score:3, Informative)
Actually, they use kernels with everything compiled as modules, and a separate initrd/initramfs to deal with loading the drivers required at boot time.
Re: (Score:3, Insightful)
Re:Bloat? (Score:4, Insightful)
The common sense of the US Government is the only thing standing between us and DRM hell? Oh dear :(
Parent
You joke, (Score:5, Interesting)
Parent
Re:You joke, (Score:5, Funny)
Linux 2.8 will compete with SunOS 6.0 as the best platform for running Duke Nukem Forever.
Parent
Re: (Score:3, Funny)
Linux 2.8 will compete with SunOS 6.0 as the best platform for running Duke Nukem Forever.
I dunno. Hurd will probably give them both a run for their money.
Anyway, isn't Duke Nukem Forever written in Perl 6?
Re:You joke, (Score:4, Insightful)
Oh, sorry, I didn't realize it was a rhetorical question.
Parent
Language (Score:3, Interesting)
More things have changed between 2.6.0 and 2.6.21 than changed between 2.0 and 2.2.
How's that?
Re: (Score:3, Funny)
Re:Does it still crash after 49.7 days?? (Score:5, Informative)
Parent
Re:Does it still crash after 49.7 days?? (Score:5, Interesting)
Parent
Re:Does it still crash after 49.7 days?? (Score:5, Funny)
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Interesting)
Re:Published? (Score:4, Informative)
(I also planned to add the number of months of development (almost 3, 80 days), but I forgot it)
Parent
No, it's just the hardware (Score:4, Insightful)
This means your CPU is much more powerful than what you really need. I used FreeBSD a bit in the 1990s, but switched to Linux because the kernel allowed me better fine tuning in the 486 CPU I had at the time.
Today the CPU is way over my needs too, but I stick to Linux because, first, I have no need to switch and, second, Linux has better hardware support than the others you mentioned.
Parent
Re:PWRficient support? (Score:4, Informative)
Since each SoC is totally different, except maybe for the CPU core, porting Linux (or any OS) to it is a little more difficult than just compiling it and loading it. Check out the arch/ppc or arch/arm directories for examples of all the different chips supported. While the work certainly isn't comparable to, say, porting Linux to an entirely different CPU architecture, it does require several new files with custom code to support things like the way interrupts are assigned to the specific functions on the SoC.
Worse, sometimes new drivers need to be written for certain on-chip peripherals, because some bonehead empire-building managers at the chipmaker wanted to justify a higher budget for their department by, instead of just re-using an existing USB controller or Ethernet controller design and plopping that onto the chip, putting together a whole team and spending months creating a new controller because it might improve performance by a whopping 5%. My last company, which made a lot of ARM-based chips, was especially guilty of this.
Parent