Subject: Re: Please Revert newlock2
To: None <firstname.lastname@example.org>
From: Bucky Katz <email@example.com>
Date: 02/20/2007 16:55:35
Andrew Doran <firstname.lastname@example.org> writes:
> It's not difficult to construct artifical benchmarks to show for
> instance, pthread_cond_wait() is now slower or that thread creation
> is now slower. Ok, but we will be tuning the new system as time goes
> on, and, for most real world applications 1:1 is only going to bring
> benefits in the long run.
Actually, it has been my experience that for most real world
applications that have significant numbers of threads, even on large
scale SMPs, m:n is more efficient.
There's almost no workload for which it is less so.
> I think it's important to note that with the release of NetBSD 5.0
> we will be able to provide working pthreads on _all_ platforms, a
> threading implementation that works on MP systems, and importantly a
> threading implementation that is robust.
As I understand it, until very recently, you were planning on
preserving m:n threads for the uniprocessor case. We're not asking
that you solve the general SA debugging problem. We're simply asking
that you leave the m:n threads for the uniproccesor case as a compile
time kernel option. We've fixed them to our satisfaction and will fix
them further if we find them broken.
What we want is something that was a goal of yours until recently and
that's technically just not that hard to do.