Linked by Thom Holwerda on Sun 4th Feb 2007 21:35 UTC, submitted by diegocg
Linux After two months of development, Linux 2.6.20 has been released. This release includes two different virtualization implementations: KVM: full-virtualization capabilities using Intel/AMD virtualization extensions and a paravirtualization implementation usable by different hypervisors. Aditionally, 2.6.20 includes PS3 support, a fault injection debugging feature, UDP-lite support, better per-process IO accounting, relative atime, relocatable x86 kernel, some x86 microoptimizations, lockless radix-tree readside, shared pagetables for hugetbl, and many other things. Read the list of changes for details.
Thread beginning with comment 209145
To read all comments associated with this story, please click here.
Hmm...
by hobgoblin on Sun 4th Feb 2007 23:46 UTC
hobgoblin
Member since:
2005-07-06

x86 relocateability? I have not checked the changelog, but whats that?

Browser: Opera/8.01 (J2ME/MIDP; Opera Mini/3.0.6636/1558; nb; U; ssr)

RE: Hmm...
by Mark Williamson on Mon 5th Feb 2007 00:19 in reply to "Hmm..."
Mark Williamson Member since:
2005-07-06

Allows you to load the kernel at a different address. e.g. I think for kdump you don't need a separately compiled kernel for your dump kernel anymore (previously you needed one that was compiled for a different, fixed base address).

Reply Parent Bookmark Score: 5

RE: Hmm...
by butters on Mon 5th Feb 2007 03:55 in reply to "Hmm..."
butters Member since:
2005-07-08

Like Mark said, previous kernel releases needed a second kernel image in order to handle crash dumps. A bunch of releases ago, the Linux kernel added kexec, a method of loading a Linux kernel image from the running kernel and turning control over to the new kernel instance. This allowed Linux to finally have crash dump support via kdump. The new image needs to be able to dump the old kernel image, so it obviously can't be loaded into the same memory range as the old image.

The new system allows kexec to load the same kernel image into a different memory range, so you don't need to jump through hoops to get a crash dump. It would be "cooler" if Linux had dump routines that could run from within the crashing kernel, but that requires being very careful and having access to a raw block device dedicated for dumps. You can't take page faults or service interrupts from dump routines that run inside a crashing kernel, so the Linux kexec/kdump approach is a more conservative design.

I'm not completely sure if the dump image can continue to run the system after the dump. If a new production image can be loaded via kexec into the original memory range, I believe that this capability would place Linux ahead of all commercial UNIX implementations in terms of downtime due to a crash dump. Very impressive!

Reply Parent Bookmark Score: 3

RE[2]: Hmm...
by hobgoblin on Mon 5th Feb 2007 09:46 in reply to "RE: Hmm..."
hobgoblin Member since:
2005-07-06

hmm, impressive indeed.

still, there would be the chance of it going from crash to crash. thereby getting nothing done as the kernel is to occupied firing up a new version of itself to take over for the old.

Reply Parent Bookmark Score: 2