From owner-freebsd-smp Tue Jun 29 14:44:24 1999 Delivered-To: freebsd-smp@freebsd.org Received: from fast.cs.utah.edu (fast.cs.utah.edu [155.99.212.1]) by hub.freebsd.org (Postfix) with ESMTP id 7464D15370 for ; Tue, 29 Jun 1999 14:44:16 -0700 (PDT) (envelope-from vanmaren@fast.cs.utah.edu) Received: (from vanmaren@localhost) by fast.cs.utah.edu (8.9.1/8.9.1) id PAA27790; Tue, 29 Jun 1999 15:44:16 -0600 (MDT) Date: Tue, 29 Jun 1999 15:44:16 -0600 (MDT) From: Kevin Van Maren Message-Id: <199906292144.PAA27790@fast.cs.utah.edu> To: tlambert@primenet.com, vanmaren@cs.utah.edu Subject: Re: high-efficiency SMP locks - submission for review Cc: freebsd-smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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