Date: Thu, 28 Feb 2002 10:09:51 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: arch@FreeBSD.org Subject: SMPng Design (Well, some of it anyways) Message-ID: <XFMail.020228100951.jhb@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
First, let me prefix this by saying that the last two weeks have been very stressful. If you guys are trying to kick me out of FreeBSD just keep it up, you almost convinced me to leave this time around. It sure seems to be your goal. :( Secondly, the changes we are making to the kernel with SMPng can't all be done in piecemeal fashion. Not all changes are 5 line commits. For example, the kernel preemption patch is rather small, however, it exposes a number of really obscure bugs that aren't easy to track down. Rather, kernel preemption is a long term goal, and having developed it in a side branch has helped give future direction as to how the kernel should go. If you guys can't handle a roadmap that has future milestones farther away than 1 week, then I have to wonder why even are doing SMPng. Also, we have most of the preemption stuff in current now. It's not optimal at the moment, but it's close enough that there is lower-hanging fruit (such as the proc locking stuff I've been doing instead) that gives us a bigger bang for the buck. Anyways, as I said at BSDCon (but was apparently ignored when I said it, just as people seem to not have noticed when I said was working on changing all the process credential stuff) I have been working on a sort of design document. It's up to about 7 pages of actual text in PS and PDF. There are some things in it that I'm sure are going to upset people. Mostly one of my themes that a lot of folks don't seem to share is this: We should not optimize yet. The kernel architecture is still in a state of flux and we need to be able to change API's when we find that the ones we have don't actually work. If we invest a lot of time optimizing the API's we have now, then it will be a big pain if we need to change that API. Also, people will not want to lose all their work doing optimization and thus will try to stall the needed API changes. I don't want to fight those battles. To reach the at least 10% worse than 4.x or better goal I announced at BSDCon for 5.0, I want us to be working on pushing down Giant by locking subsystems. Not cheating by trying to do very machine specific optimizations. I don't want i386 to meet the goal but all other arch's to be dog slow. I'd much rather have the effort spent on MI code. I know I probably just pissed a lot of you off, but I'm taking a long range view here, not a short range view. Anyways, the document as it currently stands can be found at: http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf} I will continue to add new sections and flush out the skeleton ones as I have time. The paper at the URL above will be updated as I do so. If you collectively decide as a group that I'm off my rocker and this is all crap, then I'll happily step down from SMPng and go do my work somewhere else as in that case I am obviously not the right person for the job. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.020228100951.jhb>