Bill Stouder-Studenmund <wrstuden@netbsd.org> wrote:
quoted text
> > Imagine a case of 1000 (new) pthreads which block - that would mean:
> > 1000 * (LWP creation + SA context switch) operations. Plus, LWPs for
> > VPs...
> 
> That would be the exact same LWP usage as a 1:1 threading model would 
> give. The SA process spends the time creating the LWPs between blocking 
> events while the 1:1 process created all of the same LWPs at initial 
> thread creation time.

Not exactly. To create LWP when blocking (that is, switching the context) SA
invents a lot of complexity, and hacks (eg. locking against order). Also,
inventing the limits on such flow is harder.

quoted text
> One other thing to consider is how long different context switches take. 
> The two important ones are intra-process-same-space switches (inter-LWP in 
> the kernel and inter-thread in SA userland) and user-kernel switches. When 
> I was starting the Wasabi iSCSI target, I asked around before we used (SA) 
> pthreads to implement this. I asked a number of NetBSD threading folks 
> about this.
> 
> The answer I was given was that user-kernel switches are NOTABLY more 
> expensive. Like 10x. Their numbers, not mine. So while SA is adding extra 
> steps, they are steps that aren't the most expensive thing around.

But well.. what Andrew said - let's rather spend time optimising the context
switch on such architectures like ARM - that would give overall benefit.

quoted text
> What I don't understand, though, is why we're discussing this issue like 
> this. I don't see what the NetBSD kernel loses by having both 1:1 AND SA 
> threading support. While the SA code is a fresh port, it is a fresh port 
> of the NetBSD 4 code. So it actually is something we're familiar with as a 
> project. People on this list have shown that SA does better on some work 
> loads, and other people have shown (quite spectacularly) that 1:1 performs 
> stunningly.

Bringing SA back invents more than 3000 lines of very complicated code. Why?

- To support specific backwards compatibility which we never actually
  supported (see what Andrew and Jason wrote).

- To support theoretical performance for some workload, where seems nobody in
  this mailing-list can provide a prove-of-concept test application, or even
  a reasonable SA benchmark. And no - "I saw a benchmark" or 5 years old
  graph about NPTL, unfortunately, does not say anything...

Looks ironical. Especially when people arguing more from belief, instead of
saying: "Hey, here is the example of real-world application which works with
SA much better - let's try it!"

But again, the main thing which makes me upset is adding thousands of lines
to improve few percent of theoretical cases. This breaks one of the main
software engineering principles. I thought it is not the way NetBSD goes...

-- 
Best regards,
Mindaugas
www.NetBSD.org