Quoting Thor Lancelot Simon <tls@rek.tjls.com>:
> On Mon, Jul 14, 2003 at 08:12:16AM -0700, Bill Studenmund wrote:
> > Could you please break this up into smaller pieces? Your work and
> > Stephan's has done a lot of bug fixing, and you're adding (important)
> > features. Please separate the two, and check in the bug fixes soon. :-)
> 
> I don't entirely agree.  The features added by this patch are necessary
> to address the issues with SA in combination with SMP, are they not? 
> Given
> that, and given that the current state of the SA thread code has made
> SMP
> systems largely unusable -- at least in my application, but others have
> complained of this as well -- I'd be in favor of keeping everything
> that's in this patch.

The processor affinity code is used to prevent LWPs associated with the 
same VP (virtual CPU) to run concurrently.  The LWPs in question are LWPs 
which have received a signal/event and will make an upcall immediately, 
there should be no real performance loss if they do not run concurrently.  
This is the solution I would choose for the SMP/SA problem without 
requiring a redesign of the SA kernel infrastructure.  Stephan has a 
different (according to him temporary) solution for this problem.

My solution has the advantage of allowing multiple VPs and thus user space 
concurrency.  I have moved the VP specific data to a seperate structure and 
the LWPs have a reference to this structure.

I'm really curious now what solution will finally be adopted, but I guess 
we'll have to wait until it's fait accompli[1].  

In any case this was fun ;-)

> My only comment would be that MPCPUMASK should just rely
> on MULTIPROCESSOR at least until some other affinity method is
> implemented.

I made the processor affinity code not conditional on MULTIPROCESSOR 
because it's (so far) only implemented on i386.  On i386 it should be 
conditional on MULTIPROCESSOR if it's used to solve the SA/SMP problem.

I'm going to post the processor affinity code without the SA stuff to tech-
smp, maybe someone will someday find it useful...

[1] finished
-- 
Christian Limpach <chris@pin.lu>
Think about it: #define funlink(fd) close(fd)