>    So you guys (core) choose -- do you want 4.x to reap the benefits of
>    further SMP development or not?  If you choose no, beware that without
>    this base cleanup there is *NO* chance whatsoever of any further SMP
>    work being MFC'd to 4.x.  None.  Zilch.   It will have diverged too
>    much.  

As the original author of the cil/cml code I can say I was glad to see that 
had finally put it to rest. It was a desperate hack made in an attempt to pinch
a little more performance out of the paradigm without dealing with the whole
spl() problem set.  I would have done it myself if life hadn't taken me down a 
path where I have too little time for these things...

I've been playing with test buildworlds on my server and have concluded that
we are currently kernel (big giant lock?) bound.  In my tests 3 CPUs actually
complete buildworld faster than 4.  The major solutions to SMP in the future
will come from:

 1: pushdown of the BGL into the read/write routines.
 2: kernel threads.
 3: replacement of spl() with mutex() type protection of data regions.

I am guessing that little of the above will be MFC'd into 4.0.  So the issue
of the current SMP patch set should be based on its merits alone.  I would
agree that they in themselves are worthy of MFCing.  Lets just not kid 
ourselves about major future improvements of SMP in 4.0, the biggies I
enumerate above just won't happen there.

Steve Passe     | powered by 
[EMAIL PROTECTED]     |            Symmetric MultiProcessor FreeBSD

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to