Date: Sat, 12 Jun 1999 14:16:21 +0200 (CEST) From: Soren Schmidt <sos@freebsd.dk> To: crb@ChrisBowman.com (Christopher R. Bowman) Cc: adsharma@home.com, crossd@cs.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? Message-ID: <199906121216.OAA13526@freebsd.dk> In-Reply-To: <199906121040.FAA04934@quark.ChrisBowman.com> from "Christopher R. Bowman" at "Jun 12, 1999 6:37:50 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906121216.OAA13526>