Subject: Re: Please Revert newlock2
To: Bucky Katz <firstname.lastname@example.org>
From: Simon Burge <simonb@NetBSD.org>
Date: 02/21/2007 14:08:30
Bucky Katz wrote:
> Simon Burge <simonb@NetBSD.org> writes:
> > Did you read all of Andy's message from about half an hour ago where
> > he explained why he changed this goal? Goals are allowed to
> > change...
> Well, I responded to it, so let's take it as read I read it. ;)
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.
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
> And goals should be changed back when significant new informat is made
> available -- like 'oh, there really *are* users relying on the feature
> you wish to deprecate...
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 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