On Tue, Feb 20, 2007 at 07:32:17PM -0800, Bucky Katz wrote:
> 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.

But putting the old SA code back into the kernel essentially means
abandoning all of the newlock2 work, because the old SA code has (among
other things) severe locking issues in its memory allocation (look at it;
they're obvious) and is unreasonably incestuous with the scheduler, as
well.  Other changes in newlock2 that aren't reasonable to back out if
we want modern synchronization in our kernel and reasonable performance
on multiprocessors conflict with the way the old SA implementation was;
and nobody appears to want to rework SA -- not its author, not any of
the developers who previously contributed to it in any substantial way,
and (please correct me if I'm wrong) not even you.  Since nobody wants
to do this work, this option would seem guaranteed to leave either SA
or newlock2 broken forever.

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.

Thor