Date: Thu, 24 Jun 1999 13:39:10 -0600 From: Nate Williams <nate@mt.sri.com> To: "Brian F. Feldman" <green@unixhelp.org> Cc: Karl Denninger <karl@Denninger.Net>, Doug <Doug@gorean.org>, Mark Newton <newton@internode.com.au>, drosih@rpi.edu, grog@lemis.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) Message-ID: <199906241939.NAA07731@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9906241431050.9373-100000@janus.syracuse.net> References: <19990624125855.A8051@Denninger.Net> <Pine.BSF.4.10.9906241431050.9373-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > We're adding some machines at work for (essentially) cgi > > > processing only. It was never considered to use anything less than 2 cpu > > > boxes, and the current round of testing is going so well that we're > > > seriously considering 4 cpu boxes because they are not that much more > > > expensive and our processing is highly CPU bound. I agree that redundancy > > > is a good thing, but at some point the increased network latency exceends > > > the point of diminishing returns for the redundancy factor. > > > > > > In short, increasing SMP efficiency should really be a priority > > > for N>2 systems. > > > > Agreed. But this is a BIG job, because to do that you have to solve the > > "one big kernel lock" problem and go to fine-grained locking. This is a > > non-trivial job. > > We don't need fine-grained locks. We would get good performance if we > could get (say) per-subsystem locks. In my neck of the woods (doing lots of multi-threaded stuff), that is the definition of 'fine-grained' locks, vs. 'coarse-grained' locks. What we have now is a big 'coarse-grained' lock. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906241939.NAA07731>