Date: Mon, 27 Aug 2001 10:39:23 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.org Subject: Re: Headsup! KSE Nay-sayers speak up! Message-ID: <XFMail.010827103923.jhb@FreeBSD.org> In-Reply-To: <3B8A7D66.22469D03@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27-Aug-01 Julian Elischer wrote: > 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. Note that I haven't committed preemption (largely because it doesn't work on SMP and alpha yet. :-P). However, SMPng is one large change for 5.x. Not sure how many large changes we want to do at a time. > 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. The problem becomes that if something breaks, where do you go to look for the bug? Is it a SMPng bug? Or a KSE bug? Getting SMPng to a state where a good portion (say, at least 2 major subsystems) are out from under Giant will be the first good stress testing of the concurrency and good stress testing of SMPng. It could potentially get pretty bumpy when that happens, and having KSE add to that bumpiness may make things very complicated. I wasn't in favor of KSE's in 5.0 at Usenix, but saw that I was in an obvious minority. I'm still in the minority and realize that and don't expect my opinions here to make any difference. I just wanted to voice my concerns. > What it DOES do however is make your locking code more challenging. > But that is going to have to be faced at some time.... Yes, but I'd rather face it after we've made more progress on SMPng first. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.010827103923.jhb>