Date: Sat, 12 Jun 1999 14:23:40 -0400 (EDT) From: Brian Feldman <green@unixhelp.org> To: Arun Sharma <adsharma@home.com> Cc: dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? Message-ID: <Pine.BSF.4.10.9906121416520.8587-100000@janus.syracuse.net> In-Reply-To: <m3wvx9e1eb.fsf@c62443-a.frmt1.sfba.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Jun 1999, Arun Sharma wrote:
> "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.
That's untrue if you're using asynchronous I/O.
>
> > -- 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.
Not quite as well, but it will still be much faster. Besides, FreeBSD would
perform better under load than nearly any other OS, so it's not as if it would
be slower than something else.
>
> 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.
But you can't generalize FreeBSD's usage, can you?
>
> An alternative way, which requires a good understanding of both the
> theory and implementation of the kernel is -
>
> (a) Implement per subsystem locking
That seems to be the most winning solution.
> (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.
Once again, there is no "typical" unless you try to overgeneralize and say
"FreeBSD is used mostly for XXX." This would be just an extension of a. But
this is much less of a gain (from what I conjecture). It would make sense
to have separate locks for, say, at least the I/O subsystems (all in total,
not for each one. Why do you want to parallel something that's doing DMA?),
FS interfaces, VM/trapping, and networking.
>
> 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
>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906121416520.8587-100000>