Try honey, not vinegar.
> First off, before you get all hot and bothered: SMP=1 SHOULD BE OFF BY
> DEFAULT!. No one SHOULD be running a SMP kernel on a non SMP box! Yes, it
> should not lockup.. But it's performance should be less. It should be no
> problem for a dist to ship two sets of kernels and modules, and a util to
> pick the right one.
No, because someone may install an extra CPU. At a very minimum,
the UP kernel would need to detect extra CPUs so that the init
scripts could offer to switch kernels. That is a poor solution though.
> It would be nice if a kernel could work optimally on SMP and UP. This is
> not possible however, without such monstrosities as self modifying code.
Self-modifying code reduces support problems because it eliminates
the distinction between SMP modules and UP modules.
Digital Unix uses self-modifying code with 5 options:
SMP, SMP with real-time, UP, UP with real-time, debug check
That last one seems useful, eh? With _any_ kernel, you can boot in a
mode that checks locking order.
We ought to use self-modifying code anyway, for a generic 386/486
kernel. There is a 6-byte sequence that would handle a cache issue.
(something Linus came up with a year or two ago) Some of the user
access code could be ripped out on the fly too.
>> P.S. The same is about APM stuff: APM stuff SHOULD work with SMP
>> enabled on when there are really only one processor installed.
>> Unfortunatelly looks like a 2.3 stuff -- to many places to change :-((
>> But when SMP-enabled kernel could not even START on UP comp -- that's
>> other story. This should be avoided for AT LEAST 99.9% of computers.
>
> No it shouldn't. You shouldn't be using APM with a SMP kernel.
No APM with SMP hardware is OK. No APM with an SMP kernel is bad.
(and even in the first case, power down ought to work)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/