Date: Mon, 27 Aug 2001 10:03:34 -0700 From: Julian Elischer <julian@elischer.org> To: John Baldwin <jhb@FreeBSD.org>, current@freebsd.org Subject: Re: Headsup! KSE Nay-sayers speak up! Message-ID: <3B8A7D66.22469D03@elischer.org> References: <XFMail.010827093406.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
>
> On 27-Aug-01 Julian Elischer wrote:
> > I am ready to do my megga-commit to add the first stage of KSE-threading
> > support
> > to
> > the kernel. If there is any argument as to the wisdom of this move,
> > then this is the time to speak up!
> >
> > At this stage a commit would break alpha and ia64 until
> > they are patched. From experience I can say that it's not a horrific
> > change to the machine dependent code so patches PRE commit would be
> > welcome.
>
> Just to get this out in the public: I for one think 5.x has enough changes in
> it and would like for KSE to be postponed to 6.0-current and 6.0-release. I
> know that I am in the minority on this, but wanted to say it anyways. It
> doesn't mean I don't like the KSE work or anything like that (I've even helped
> out on it some), I just think we have enough work in our basket. Also, I'll
> point out that p4's merging abilities make tracking current relatively easy,
> much more so than if Julian was maintaining a separate tree with this patch and
> having to keep updating current and manually merge it all the time.
>
> </stump>
well I expected this to some extent..
This is why I asked.. I want to get it out where it can be discussed.
the same could also be said for full pre-emption and SMP-NG.
It is also interestingto note that KSE isn't the only game in town.
The new PTNG package looks interesting, using normal process rforking
to generate a pthreads environment. (It's a rewrite, not a port of
linux threads).
All I have done is brought the kernel to a state where
it is READY for work to break the 1:1 barrier. It is basically
logically exactly the same kernel as in -current. I think it introduces
far fewer logical changes than, say, the pre-emption code,
or the locking code. I agree that we could wait. I don't however think we
should. I'd rather have ONE broken period than two. At USENIX we agreed that
if I got this done it would be committed and work could start to
provide the facilities that Dan and Chris need for the Userland
code to develop. Remember, that unless you turn this on, it's
a very complicated NOP.
What P4 does is really irrelevent because there are only 4 people using it..
(or is that 3?). It needs a distribution channel, and P4 isn't it.
(at least not at the moment.)
What it DOES do however is make your locking code more challenging.
But that is going to have to be faced at some time....
--
+------------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ julian@elischer.org +------>x USA \ a very strange
| ( OZ ) \___ ___ | country !
+- X_.---._/ presently in San Francisco \_/ \\
v
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?3B8A7D66.22469D03>