Date: Tue, 29 Jun 1999 15:44:16 -0600 (MDT) From: Kevin Van Maren <vanmaren@fast.cs.utah.edu> To: tlambert@primenet.com, vanmaren@cs.utah.edu Cc: freebsd-smp@FreeBSD.ORG Subject: Re: high-efficiency SMP locks - submission for review Message-ID: <199906292144.PAA27790@fast.cs.utah.edu>
next in thread | raw e-mail | index | archive | help
> > 5) Very few people both know enough about the kernel internals and > > multiprocessor/multi-threaded locking to do the job "right". > > I don't think that's true. I count at least 5 people people in > the FreeBSD camp, not including myself (Simon Shapiro, Bakul Shah, > John Dyson, et. al.), just off the top of my head (e.g. if your > name belong here and I didn't put you here, I'm not snubbing you). You are agreeing with me! I was implying the number was small, not zero. There are maybe 5 to 50, not 500-5000. Perhaps a dozen people are really capable of doing the work at this point; the question is how many of the handful have the time and motivation to work on it? This is the downside of an "open source" OS: big projects that take a long time are less likely to be fully staffed. Sun could afford 10 man-years (or whatever it was) to multi-thread solaris/SVR4. We probably can't... Still, a few man-months can get a lot done, if the right person is working on it. > > 6) The method most likely to succeed will be evolutionary; there is > > simply too much code to change everything at once and get it all working. > > I doubt this. It's unlikely to be possible to achieve Solaris > or even NT level SMP performance without a willingness to rewire > the guts of things. > > It's possible to break the tasks down by subsystem, but after you > do that, there's a limit to how divisible the tasks are. I agree with all this. I am saying that starting from where we are now, and going straight into a fully-preemptable, multi-threaded kernel with fine-grained locking isn't likely to be the most fruitful approach in the short term. I also recall hearing that Solaris was slower on a uniprocessor than FreeBSD, partly due to the locking/synchronization in the kernel. > I think a good approach would be to divorce the idea of user space > process context (user stack and memory map) and kernel space > process context (kernel stack per kernel entry, user space memory > map, sleep context) as a first run. Once we have the idea that > the things that run in the kernel aren't the same as the things in > user space, then kernel work can be scheduled sepeerately from user > space work to achive parallelism wins (e.g. your async read request > is serviced by CPU 2 while your program continues to run on CPU 0). That is an interesting idea. Add multiple kernel stacks per user process, and you have threading ;-) > FreeBSD did worse than Linux, both SMP and UP. I didn't see any FreeBSD numbers; I'll have to go look again. It wasn't that long ago FreeBSD was beating the pants off Linux. I guess we've been standing too still for too long. Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906292144.PAA27790>