Simon Burge <simonb@NetBSD.org> writes:

> Bucky Katz wrote:
>
>> Simon Burge <simonb@NetBSD.org> writes:

> What I meant with "... all of ..." was you didn't respond to any of
> the reasons that Andy mentioned as to _why_ he didn't pursue SA any
> longer and switched to a 1:1 model.  You did reply to the rest of
> his message.

Since I haven't asked him to abandon 1:1, I didn't think there was
anything there to respond to.

> I'm sure if you or someone else wants to provide clean patches that
> allow SA to work with newlock2 (as opposed to just turning off
> newlock2 altogether and effectively "reverting" it) then they'll be
> gratefully accepted.

But I "or someone else" did not remove functionality that the NetBSD
user community was relying on without even asking if they were.

This is the crux of this whole discussion.

> The changes being made are to deprecate one style of threading for
> another.  We will still have threading functionality.  Implementions
> of subsystems can change over time.  The current threads
> implementation doesn't scale for MP and has had issues on other
> architectures (and possibly still has?  sparc64 has been one of the
> big ones here), so something needed to be done.

It's not 'one style of threading for another', though. It's a whole
lot of performance changes that even Andrew has implicitly admitted
degrade pthread performance.

Actually, since no one has even bothered to benchmark newlock2 against
pthreads, as far as I can tell, you don't have any evidence that you
haven't traded a decrease in threaded performance for a simpler
implementation.

> It does sound like there's a chance ARM could be affected
> performance-wise, but also at this stage we don't have benchmark
> data for ARM to say how much of an issue this really is.  If the
> performance on one architecture turns out to be an issue, and it's
> the only issue we have across the board across multiple
> architectures, then it's still a win overall.

It's not going to just be ARM.  ARM matters to me personally because
it's the architecture I need the performance on, but anyone who is
using "lots" of threads will see performance degredation, even on SMP,
from not using M:N threading. Andrew hinted at the reasons when he
mentioned condition waiting.

I no longer have it in my personal possession, but I'm aware of
performance data going back to 1985 that shows this. There's a
_reason_ why Cray put m:n threading into Unicos and it had nothing to
do with uniprocessor performance.

But it's not just ARM you don't have benchmark data for. As far as
I've been able to discover, you've got no pthreads benchmarks on any
platform for newlock2.

Please realize that I didn't ask for the revert because I naively want
-current to be like -release. I work in pre-alpha branches all the time
and know exactly what to expect.  I asked for the revert (which I'm
not asking for now) because everything I learned about newlock2 says
it's too raw for an alpha branch and everyone would be better off if
it got shook out further in its own branch first.