From owner-freebsd-hackers Thu Jun 24 13:25:17 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id C18DB14F9A for ; Thu, 24 Jun 1999 13:25:07 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id QAA04942; Thu, 24 Jun 1999 16:22:38 -0400 (EDT) Date: Thu, 24 Jun 1999 15:22:36 -0500 (EST) From: Alfred Perlstein To: Karl Denninger Cc: "Brian F. Feldman" , Doug , Mark Newton , drosih@rpi.edu, grog@lemis.com, mike@smith.net.au, hackers@FreeBSD.ORG Subject: Re: Microsoft performance (was: ...) In-Reply-To: <19990624145755.B8280@Denninger.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 24 Jun 1999, Karl Denninger wrote: > On Thu, Jun 24, 1999 at 02:33:10PM -0400, Brian F. Feldman wrote: > > On Thu, 24 Jun 1999, Karl Denninger wrote: > > > > > On Thu, Jun 24, 1999 at 10:54:37AM -0700, Doug wrote: > > > > 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. > > That's still a non-trivial task. :-) A simple start would be to explicitly put a macro or call in each syscall to push down the lock. That way people can move that macro farther and farther down in the syscall code path, hopefully removing it entirely in some cases. I think having the call at the beginning of each syscall would motivate people into doing that sort of work. "Hey, y'know getppid() is safe, i'll just take the lock out." "this function xxx() is safe until this point I can process a lot before actually needing this lock..." "y'know I just have a structure that's not accessable to any other calls that i'm going to fill in, i'll just lift the lock right here" "if I just do this something here, I really am re-entrant and safe.." Providing a simple api for spinlocks and mutexes would be very nice. If some of the FreeBSD gods (core) said something along the lines of we'd like to see the process table have XXX method of access and locking people will code it, the same way with the many other subsystems. Things like pmap and UFS and INET will be a royal pain to get SMP safe, however baby steps towards lifting the lock for simpler subsystems will lead the way. FreeBSD has the most intellegent people in the industry working together, all that is needed is a starting point. -Alfred Perlstein - [bright@rush.net|bright@wintelcom.net] systems administrator and programmer Win Telecom - http://www.wintelcom.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message