Date: 12 Jun 1999 11:09:48 -0700 From: Arun Sharma <adsharma@home.com> To: dyson@iquest.net Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? Message-ID: <m3wvx9e1eb.fsf@c62443-a.frmt1.sfba.home.com> In-Reply-To: "John S. Dyson"'s message of "Sat, 12 Jun 1999 11:53:27 -0500 (EST)" References: <199906121653.LAA06434@dyson.iquest.net.>
next in thread | previous in thread | raw e-mail | index | archive | help
"John S. Dyson" <dyson@iquest.net> writes:
> 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
Fine grained locking is hard - but it isn't exactly rocket
science. It's been tackled in a number of OSes, papers have been
written about it.
> -- 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.
Sure. But 2 and 4-way boxes are becoming more and more mainstream. And
any IO bound job is not going to perform well on FreeBSD because of
giant locking.
One way of tackling the problem is - to implement per lock profiling
and detect which locks are being contested heavily and try breaking
them down. That would be a practical way of doing things.
An alternative way, which requires a good understanding of both the
theory and implementation of the kernel is -
(a) Implement per subsystem locking
(b) Figure out in a "typical" workload, how much time is being spent
in which subsystem and try increasing parallelism (i.e. finer
grained locking) in subsystems where more time is being spent.
The result of this approach should be more logical, cleaner and
possibly better performing than the previous one.
-Arun
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?m3wvx9e1eb.fsf>