Date: Tue, 28 Aug 2001 00:12:49 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Jim Bryant <kc5vdj@yahoo.com>, current@FreeBSD.org, Robert Watson <rwatson@FreeBSD.org>, Peter Wemm <peter@wemm.org>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Julian Elischer <julian@elischer.org>, Bosko Milekic <bmilekic@technokratis.com> Subject: Re: KSE kernel comparissons Message-ID: <3B8B4471.28047A50@mindspring.com> References: <XFMail.010827164931.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Not to put too fine of a point on it, and hopefully, this
won't be taken as a personal attack, but...
[ Mr. X ] wrote:
> [ Mr. W ] wrote:
> > As I recall, *total* "functionality" of the subsystems wasn't promised for
> > 5.0-R, but the infrastructure *was* promised. I expect
> > you are reponding to my post in the other thread...
>
> Grr, do you develop software? Hmm, well, no matter what you do,
> I'm sure we can come up with an example of having two enormous
> changes being made at the same time. It's painful, it's more
> painful than doing them one at a time.
You've repeatedly implied that you think that large things
can not be worked on by seperate teams and successfully
integrated. This goes against nearly everything I have ever
done in my more than two decade career as a paid software
engineer. My first paid project was in 1979 in high school,
in 6502 assembly, working on a team with two other people.
Things _can_ be concurrently developed successfully; work was
done by CSRG and Genentech on the BSD 4.4 code, while at the
same time the University of Guelph was writing the NFSv3
implementation, and John Heidemann was authoring the VFS
stacking system. All of these things were successfully brought
into the BSD 4.4 code base, and released in the BSD 4.4-Lite
and 4.4-Lite2 releases, all in a short time frame, with a small
group (about 6) academic programmers managing the integration
(not even including the more minor contributions).
This isn't rocket science -- but it _is_ computer science.
> Right now the patchset is indeed benign, but trying to split
> up KSE's at the same time as the kernel is being ripped apart
> to be locked down is going to cause much frustration with
> things breaking due to weird combinations of things that
> worked fine in each other's local trees.
If this is the problem you see, it is greatly exaggerated
here by these statements.
First off, no one has suggested that the KSE work be taken
further within the main source tree.
Secondly, the SMPng work is taking place on the HEAD branch;
this was arguably a mistake, in 20/20 hindsight brought on
by the current discussion. As a result, we have a "some pigs
are more equal than others" situation: by virtue of being on
the HEAD, SMPng is in a position to disrupt all other work.
This is bad: it doesn't even have a proven track record with
addressing the issues it was supposedly intended to address...
CPU scaling to even a moderate number of CPUs, without an
exponential fall-off between N and N+1 CPUs, as N becomes
a large single digit integer, and the ability to utilize the
additional CPU power for real work. Note that this latter was
supposed to be addressed by providing a new threads subsystem.
I don't think there is any intent to work on splitting KSEs up
in the HEAD; I think the KSE developers agree with the rest of
us, that the HEAD is too unstable for general developement not
directly related to SMPng.
However, now that it is _relatively_ stable, it is a _VERY GOOD_
time to synchronize other projects which are _ALSO_ relatively
stable, tag, and let them diverge into instability again, if
they are destined to do so. Realize that Julian has already
stated that he will re-snapshot into P4 the code after the merge,
and work on "the dreaded KSE splitting" there.
> Why in the world would people protest putting KSE in 6.0?
Maybe it has something to do with the general consensus of
the committers and -core membership attending Usenix that if
Julian could finish the work by August, that it would be
committed for the 5.0 release?
I can imagine that it must be nerve-wracking, not being given
the promised go-ahead, while at the same time people are going
ahead and committing SMPng changes which might destabilize HEAD
and send it spinning out of control again, away from a safe
synchronization point.
> If a task takes X amount of effort, and you only have Y < X amount
> of effort to expend, then you aren't going to achieve the task.
> You can't change that by decreeing that this feature adn that
> feature will be in FreeBSD at such and such a date because Jordan
> said so 2 years ago. Do you realize how long it has taken
> commercial OS's with several full-time _paid_ employees to achieve
> the same tasks we are doing in SMPng and KSE?
4 years, form the first introduction of paged memory management
to full SMP and kernel threading, for SVR4.0.2, coming from SVR3;
so going back to the original SMP code from October of 1995,
FreeBSD has had 6 years to do what the commercial folks did in 4, in
an almost impossibly political climate, with a source tree divided
into three parts so as to try to preclude cross subsystem changes
-- changes of the type necessary to get the work done. Without the
USL organizational handicap, I think that Art Sabsovitch, Steve
Baumel, and crew could probably have done the work in 2 years (3 at
the outside). And there were only about 10 of them, total...
PS: If task A takes X amount of effort, and task B takes Y amount
of effort, and you only have Z < (X + Y) amount of effort to
expend, and you are using a volunteer workforce, then they will
work on whatever the hell they want to work on, and you aren't
going to be able to schedule task A to complete before task B
based on wishful thinking or source tree storm trooper tactics.
> Perhaps I'm being uber-paranoid about this. *sigh*
That'd be my vote... 8-) 8-).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B8B4471.28047A50>