Date: Sun, 27 Jun 1999 11:09:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Doug Rabson <dfr@nlsystems.com> Cc: Peter Wemm <peter@netplex.com.au>, current@freebsd.org, mckusick@mckusick.com Subject: Re: BUF_LOCK() related panic.. Message-ID: <199906271809.LAA14643@apollo.backplane.com> References: <Pine.BSF.4.05.9906271126390.80685-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:In the long term, we probably need an spl-aware simplelock or maybe the
:cunning no-cost interrupt thread scheme which BSDi are using.
:
:--
:Doug Rabson Mail: dfr@nlsystems.com
:Nonlinear Systems Ltd. Phone: +44 181 442 9037
I really like the idea of a cunning no-cost interrupt thread scheme,
I didn't realize that BSDi had moved to it!
Doing this would allow us to remove easily half the spl management
code and would allow us to fix simplelocks - to implement them the way
they ought to be implemented.
--
On a related topic, I've done some syscall overhead measurements w/
SMP verses non-SMP systems that people may be interested in. The
SMP/patched version includes a patch that Alan is going to commit
soon ( a relatively simple removal of unnecessary locks surrounding
an already-atomic assembly operation ). The cpu's are P-III/450's.
no SMP Null syscall: 3532 nanoseconds
SMP Null syscall: 6750 nanoseconds
SMP/patched Null syscall: 6533 nanoseconds
In comparison, I believe the Linux syscall overhead is on the order
of 1 uS. Not that I am concerned about a few measily microseconds,
but this does show that we have a ways to go in our SMP work. There
is a lot of potential for improvement.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906271809.LAA14643>