Subject: Re: Please Revert newlock2
To: Bucky Katz <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 02/20/2007 16:43:30
Content-Type: text/plain; charset=us-ascii
On Tue, Feb 20, 2007 at 03:37:05PM -0800, Bucky Katz wrote:
> Jason Thorpe <email@example.com> writes:
> > On Feb 20, 2007, at 2:45 PM, Bucky Katz wrote:
> >> I dunno. #ifdefing out the "new scheduling infrastructure" should be
> >> just as easy as #ifdefing in the SA code.
> >> Not seeing a problem here.
> > I am -- you're basically asking for it to be backed out, and that
> > simply isn't going to happen.
> That's a social problem. I was talking about there not being any
> actual difficulty in accomplishing the goal.
Actually, it's not a social problem. Maintaining two totally divergent=20
code bases is a technical problem.
Many parts of the pre-newlock2 NetBSD kernel would not scale well beyond
big-lock. As I noted before, the locks we had would, themselves, not work
well. The scheduler doesn't work well. Interrupts don't work well. Way too
much silently depends on there being one major kernel lock.
The scheduler has changed, and interrupt handling is next on the list.
It's one thing for there to ba an SA option that can be enabled in a UP=20
kernel. It's another for there to be two different scheduler=20
infrastructuers and two different interrupt infrastructures. The latter is=
> I also wasn't aware that you spoke for core. Where I last left this
> with core was an investigation to see how reasonable it would be to
> do, that's been hampered by tip'o'tree at first not building and now
> not running on ARM.
Bucky, what do you want?
You claim you want things to work. However you are being routinely
abrasive and rude. This behavior pattern is not encouraging others to
actually help you. You have been told this. This is a volunteer project,
and as such it matters how you ask for things.
So why, if you really want things to work, are you continuing to behave in=
a manner that you have been told will not encourage others to make SA or=20
While Jason is not core, he started the newlock branch way back when. He
also knows a fair amount about how the scheduler works and how this part
of the kernel works. His input, that a revived SA would need to be adapted
to cope with a changed scheduler, is the exact kind of input core would=20
need to answer your request.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----