Re: [PATCH] x86_64: x86_64 version of the smp alternative patch.

[Dave Jones <davej@redhat.com>]

On Mon, Jun 26, 2006 at 07:00:46PM +0000, Linux Kernel wrote:
 > commit d167a51877e94dda73dd656c51f363502309f713
 > tree eb02c2974b61777f575dfdc07d4c2adf83bde434
 > parent 240cd6a80642da528bfa382ec2ae4e3cb8991ea7
 > author Gerd Hoffmann <kraxel@suse.de> Mon, 26 Jun 2006 13:56:16 +0200
 > committer Linus Torvalds <torvalds@g5.osdl.org> Tue, 27 Jun 2006 00:48:14 -0700
 > 
 > [PATCH] x86_64: x86_64 version of the smp alternative patch.
 > 
 > Changes are largely identical to the i386 version:
 > 
 >  * alternative #define are moved to the new alternative.h file.
 >  * one new elf section with pointers to the lock prefixes which can be
 >    nop'ed out for non-smp.
 >  * two new elf sections simliar to the "classic" alternatives to
 >    replace SMP code with simpler UP code.
 >  * fixup headers to use alternative.h instead of defining their own
 >    LOCK / LOCK_PREFIX macros.
 > 
 > The patch reuses the i386 version of the alternatives code to avoid code
 > duplication.  The code in alternatives.c was shuffled around a bit to
 > reduce the number of #ifdefs needed.  It also got some tweaks needed for
 > x86_64 (vsyscall page handling) and new features (noreplacement option
 > which was x86_64 only up to now).  Debug printk's are changed from
 > compile-time to runtime.

This has one behaviour slightly different to the i386 version however.
If you boot an SMP machine it does this..

SMP: Allowing 4 CPUs, 2 hotplug CPUs
Initializing CPU#0
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
CPU0: Thermal monitoring enabled (TM1)
SMP alternatives: switching to UP code
..
SMP alternatives: switching to SMP code
Booting processor 1/2 APIC 0x1
Initializing CPU#1

Seems wasteful (and noisy) to be doing this twice during boot.

		Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/