On Tue, Feb 20, 2007 at 09:24:54PM -0800, Bucky Katz wrote:
> Thor Lancelot Simon <tls@rek.tjls.com> writes:
> 
> > But putting the old SA code back into the kernel essentially means
> > abandoning all of the newlock2 work,
> 
> Y'all keep trying to make this into an either/or. It ain't one of
> them.

Well, it's a lot easier to say that when you snip the context.  I looked
at the code and it looks to me like a fairly significant amount of work
to adjust the SA kernel code for newlock2 (I pointed out two areas that
look troublesome to me).  It evidently looks that way to Andy, and to
Jason, and to a number of other people.  If it doesn't look that way to
you, what can I say, we have a disagreement, it seems -- but we _still_
don't have anyone stepping forward to do that work.

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.

> > Assuming the people trying to fix the ARM ports can get them to
> > where your hardware works again, some kind of benchmark showing the
> > degradation in the metrics you care about most might help show what
> > needs to be done, and how urgently, to restore performance for your
> > application.
> 
> I'm giving up. I'd like our stuff pulled up into 4.0-beta so we don't
> have to deal with this.

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.

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.  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.

Thor