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 majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
