On Mon, Jul 14, 2003 at 08:12:16AM -0700, Bill Studenmund wrote:
> On Fri, 11 Jul 2003, Christian Limpach wrote:
> 
> > Hello!
> >
> > I have made the necessary changes to allow a threaded application to use
> > multiple CPUs if available.  So far this was not possible because an
> > SA-application could only have one active thread.  Now top shows that my
> > simple test program which creates several cpu-hungry threads uses close to
> > 200% on my otherwise idle two-cpu machine.  transcode used to encode at
> > 3fps, it's now encoding at almost 5fps (before it crashes :-().
> >
> > The patch adds concurrency support.  It also adds support for cpu-affinity-
> > masks (options MPCPUMASK in your kernel config file) which is used to
> > address the SMP-specific SA-problems (LWPs fighting over the VP).  Finally
> > it includes large parts from Stephan Uphoff's patch to address the
> > signal/memory problems.  It's missing locking of the SA data structures
> > within the kernel and this will occasionally terminate an application or
> > even panic.
> 
> 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

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.  My only comment would be that MPCPUMASK should just rely
on MULTIPROCESSOR at least until some other affinity method is implemented.

We don't currently support any systems with 512 or even with 16 CPUs.  When
we actually start to approach the point where a 32-bit mask won't do -- if,
indeed, we ever get there at all -- it seems to me that that would be an
appropriate time to spend a lot of effort on another affinity method...

For the moment, I would very much like my SMP systems to not be trivially
crashable by inappropriate use of the SA syscalls; and I would be very
happy to get the gain in concurrency offered by the way Christian has
chosen to do that, too.