cvs commit: www/en/releases/6.1R todo.sgml

[Robert Watson]

On Thu, 26 Jan 2006, Ceri Davies wrote:

> On Thu, Jan 26, 2006 at 09:57:12AM +0000, Murray Stokely wrote:
>> murray      2006-01-26 09:57:12 UTC
>>
>>   FreeBSD doc repository
>>
>>   Modified files:
>>     en/releases/6.1R     todo.sgml
>>   Log:
>>   Add kbdmux and sysinstall smp kernel install items from the ideas page
>>   to the 6.1 Desired Features list.
>
> I think it's a little late to mess with sysinstall to that extent for 6.1. 
> Sounds like the kind of thing that could sit in -CURRENT for months, but 
> hardly anyone would actually be using it.  It seems that the main problem 
> with sysinstall is that hardly any of our developers use it.
>
> On to the question: how often does an SMP kernel fail to boot where a UP one 
> might work?  I remember that this used to be a problem, but if it's still 
> "too often", can we have just the bits that probe for an mptable (or however 
> we determine that there is more that one processor) in the UP kernel without 
> suffering that instability?
>
> What I'm basically asking is how much of the SMP code is really required 
> just to detect MP hardware?

SMP kernels now pretty much universally run on UP systems, thanks to work John 
did a couple of years ago.  The problem has historically been a performance 
once: the overhead of all the atomic instructions to run an SMP kernel on a UP 
system is significant.  We're working gradually to improve that, but it's 
still quite noticeable.  There has been talk of run-time compiling/relinking 
to use different versions of mutexes (and all that), but no progress as far as 
I know.  I can't speak to how much information the loader has/needs to decide 
if it should auto-load an SMP kernel.  A simpler version of the world says 
that you have an SMP kernel in sysinstall, and based on it probing CPUs, it 
sets the default kernel in the install to GENERIC or SMP.

Robert N M Watson