Thor Lancelot Simon <tls@rek.tjls.com> writes:

> If we did, this problem wouldn't exist.  But we don't.  The SA code
> can not simply be magically dropped into a newlock2 kernel with no
> changes; it wouldn't even compile.  So that, clearly, is not on the
> menu, since I assume you'd like the operating system to compile.

I got that. I gave up. You may stop trying to convince me that you are
unable to do this now. Fixing this problem is beyond the NetBSD
developers. Understood.

> Please, take a deep breath and look at it from the other point of
> view for a moment.  You're frustrated about a performance
> degradation that you say a code change has caused for your
> application, but you're "giving up" when asked to quantify how much
> the actual impact is, instead of just offering general observations
> about what the difference between some _other_ 1:1 and M:N threading
> systems has been.

I'm not frustrated with the performance degradation. I'm frustrated
with the way y'all handled dropping the feature.

I'm "giving up" because y'all have made it abundantly clear to me that
you're not going to fix the problem.  Even I know when the situation
is hopless.

Please don't start a benchmarking pissing contest with me, as y'all
haven't done _any_ pthread benchmarking on 1:1, although Andy admits
that he knows of situations in which it will be slower.

> It is probably the case that any changes you've fed back to NetBSD can
> go into, if not 4.0, some future 4.x branch release.

OK, now I'm getting _really_ frustrated.  I was told, on current, that
it would be easy to get our changes pulled up into 4.0.  I even recall
someone volunteering to do so.  Are you now saying you're not even
willing to do that?

>  But it is also the case that we would, in fact, like to provide
> reasonable performance for your application in NetBSD going forward,
> which will not exactly be easy to do if you won't quantify how much
> this change which you say hurt it did, in fact, hurt it.

You know, y'all have been whining at me all day about stopping this
discussion and I tried to stop it, but if you want it to continue,
fine.

First, y'all don't even have any baseline benchmarks of pthreads for
before and after comparison.  Get back to me when you can show that
1:1 is faster or scales better for pthreads on _any_ architecture and
then we can quantify it on ours. 

Second, it's a _lot_ of work for me to do before and after benchmarks,
and unless you're willing to believablly commit to an M:N thread
implementation if I show a problem, I'm not interested in doing the
benchmarks.  And we both know that you're not willling to commit.

It's nice that tip'o'tree runs on Matt's shark. But Matt's shark isn't
sitting on my desk failing to boot; my (armv4) TS7200 is.

But even if OMAP suddenly magically worked on my OSK5912, you forget
that I've got a bunch of subsystems, drivers, and libpthread changes
I've got to port to tip'o'tree in order to even do an after benchmark;

Since there's no win/win here, let's go for the least harmful
lose/lose: y'all be nice and put our OMAP port and other fixes into
4.0 and we'll live with that for the next 18 months or more.