From owner-freebsd-hackers Sat Jun 12 11:16:20 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from janus.syracuse.net (janus.syracuse.net [205.232.47.15]) by hub.freebsd.org (Postfix) with ESMTP id 860FA14E84 for ; Sat, 12 Jun 1999 11:16:17 -0700 (PDT) (envelope-from green@unixhelp.org) Received: from localhost (green@localhost) by janus.syracuse.net (8.9.2/8.8.7) with ESMTP id OAA08613; Sat, 12 Jun 1999 14:14:09 -0400 (EDT) Date: Sat, 12 Jun 1999 14:14:09 -0400 (EDT) From: Brian Feldman X-Sender: green@janus.syracuse.net To: "John S. Dyson" Cc: Soren Schmidt , "Christopher R. Bowman" , adsharma@home.com, crossd@cs.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? In-Reply-To: <199906121653.LAA06434@dyson.iquest.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 Sat, 12 Jun 1999, John S. Dyson wrote: > Soren Schmidt said: > [Charset ISO-8859-1 unsupported, filtering to ASCII...] > > It seems Christopher R. Bowman wrote: > > [exelent explanation snipped] > > > The alternative to the Giant Kernel Lock(tm) is so called fine grained locking > > > wherein locking is pushed down closer to the data structures. In fine grained > > > locking two processors might be executing in the kernel at the same time, but > > > only if they didn't need the same resources. On might be doing a disk read > > > while the other queues up a character for the serial port. The fine grained > > > lock has the potential for higher parallelism and thus better throughput since > > > process may not have to wait as long, but the larger number of locks with their > > > many required lock and unlock operations add overhead and further the design is > > > more difficult and error prone since the interaction of the numerous locks may > > > result in deadlock or livelock situations every bit as problematical as the > > > problem they try to solve. > > > > There are also those of us that dont belive in finegrained locking, exactly > > because of all the small locks you have to check/lock/open, the overhead is > > not worth it. > > > Finegrained locking either requires developers with IQ's of 200 or higher, > or a different kernel structure. I suggest that finegrained locking is cool, > and can be intelligently used to mitigate (but not solve) the effects of > lots of problems -- however, it would be unwise to embark on an effort to make > the FreeBSD kernel into an efficent 16way SMP kernel by using finegrained > locking all over the place. But your microkernel-hybrid BSD will do 16way SMP with a fully-parallelized kernel? > > -- > John | Never try to teach a pig to sing, > dyson@iquest.net | it makes one look stupid > jdyson@nc.com | and it irritates the pig. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > Brian Feldman _ __ ___ ____ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message