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>