From owner-freebsd-hackers Sat Jun 12 5:16:44 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from freebsd.dk (freebsd.dk [212.242.42.178]) by hub.freebsd.org (Postfix) with ESMTP id 85A6714DF2 for ; Sat, 12 Jun 1999 05:16:40 -0700 (PDT) (envelope-from sos@freebsd.dk) Received: (from sos@localhost) by freebsd.dk (8.9.1/8.9.1) id OAA13526; Sat, 12 Jun 1999 14:16:21 +0200 (CEST) (envelope-from sos) From: Soren Schmidt Message-Id: <199906121216.OAA13526@freebsd.dk> Subject: Re: High syscall overhead? In-Reply-To: <199906121040.FAA04934@quark.ChrisBowman.com> from "Christopher R. Bowman" at "Jun 12, 1999 6:37:50 am" To: crb@ChrisBowman.com (Christopher R. Bowman) Date: Sat, 12 Jun 1999 14:16:21 +0200 (CEST) Cc: adsharma@home.com, crossd@cs.rpi.edu, freebsd-hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. I think a model where locks placed around resonably sized subsystems is the way to go, and can be made much easier to understand and free from (too many) bugs. I did some experiments some time ago with locks around each devicedriver, the netsubsystem, the vmsubsystem, the filesubsystem and the rest, and it performed admirably. Unfortunately I lost all that work due to "unforeseen physical happenings", but is was not that big a deal to do... I think we should consider it very carefully before going the finegrained lock route, it really doesn't give you that much in real world situations. -Søren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message