public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* 2.6.17-rc3 -- SMP alternatives: switching to UP code
@ 2006-05-10  0:30 Rene Herman
  2006-05-10  1:55 ` Chase Venters
  2006-05-10  9:28 ` Gerd Hoffmann
  0 siblings, 2 replies; 11+ messages in thread
From: Rene Herman @ 2006-05-10  0:30 UTC (permalink / raw)
  To: Linux Kernel

Hi list.

I just noticed this in the 2.6.17-rc3 dmesg:

===
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 0k freed
ACPI: setting ELCR to 0400 (from 1608)
===

Should I be seeing this "SMP alternatives" thing on a !CONFIG_SMP 
kernel? It does say 0k, but something is apparently being done at 
runtime still. Why?

Rene.

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: [patch] SMP alternatives: skip with UP kernels.
@ 2006-05-11 16:22 Mikael Pettersson
  2006-05-11 18:28 ` Andi Kleen
  0 siblings, 1 reply; 11+ messages in thread
From: Mikael Pettersson @ 2006-05-11 16:22 UTC (permalink / raw)
  To: kraxel, rene.herman; +Cc: linux-kernel

On Thu, 11 May 2006 14:13:22 +0200, Gerd Hoffmann wrote:
>+	if (0 == (__smp_alt_end - __smp_alt_begin))
>+		return; /* no tables, nothing to patch (UP kernel) */

That's an unnecessarily obscure way of stating the obvious:

	if (__smp_alt_end == __smp_alt_begin)

^ permalink raw reply	[flat|nested] 11+ messages in thread
* Re: [patch] SMP alternatives: skip with UP kernels.
@ 2006-05-11 21:18 Mikael Pettersson
  0 siblings, 0 replies; 11+ messages in thread
From: Mikael Pettersson @ 2006-05-11 21:18 UTC (permalink / raw)
  To: ak; +Cc: kraxel, linux-kernel

On 11 May 2006 20:28:09 +0200, Andi Kleen wrote:
>Mikael Pettersson <mikpe@it.uu.se> writes:
>
>> On Thu, 11 May 2006 14:13:22 +0200, Gerd Hoffmann wrote:
>> >+	if (0 == (__smp_alt_end - __smp_alt_begin))
>> >+		return; /* no tables, nothing to patch (UP kernel) */
>> 
>> That's an unnecessarily obscure way of stating the obvious:
>> 
>> 	if (__smp_alt_end == __smp_alt_begin)
>
>iirc ISO-C guarantees that symbols have different values and the
>optimizer could possibly make use of that fact. So you might actually
>need some RELOC_HIDE()s to make this safe.

OK, I didn't consider that (with "extern $type a[], b[];", "a == b"
is false by definition). However, the (0 == (_ - _)) version is no
safer, since a compiler can legally turn it back to a single "==".

Since you brought up the "rules of C" argument: the
(__smp_alt_end - __smp_alt_begin) expression is undefined because
pointer subtraction is only valid if both pointers point into
the same object (or just after it), which isn't the case here.

A plain "==" with RELOC_HIDE() on the operands would be best IMO.

/Mikael

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2006-05-15 21:41 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-10  0:30 2.6.17-rc3 -- SMP alternatives: switching to UP code Rene Herman
2006-05-10  1:55 ` Chase Venters
2006-05-10  9:28 ` Gerd Hoffmann
2006-05-10 11:41   ` Rene Herman
2006-05-11 12:13     ` [patch] SMP alternatives: skip with UP kernels Gerd Hoffmann
2006-05-11 21:07       ` Rene Herman
2006-05-12 11:41         ` Gerd Hoffmann
2006-05-15 21:41           ` Rene Herman
  -- strict thread matches above, loose matches on Subject: below --
2006-05-11 16:22 Mikael Pettersson
2006-05-11 18:28 ` Andi Kleen
2006-05-11 21:18 Mikael Pettersson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox