Date: Wed, 24 May 2000 20:45:34 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Paterson <cp@bsdi.com> Cc: Terry Lambert <tlambert@primenet.com>, arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005250345.UAA78676@apollo.backplane.com> References: <200005250228.UAA16415@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: We are seeing 30 clock ticks for a locked mutex
:operation. Only 10 if you take out the lock for UP
:systems. (hopefully I did the math right.) I just don't see how
:putting a function call is going to be cheap relatively.
:
: Is it possible that you are hitting so many
:spin locks that the function calltime gets burried.
:
:Chuck
Function call overhead is around 17 nS (On a PIII 450) in
the cache case.
A locked instruction of any sort, non-contending, eats
73 nS.
A locked instruction with the second cpu doing a contending locked
instruction costs 322 nS on EACH cpu. <<<<<<<<<<<<< VERY EXPENSIVE
The non-locked unlock operation eats one clock cycle (less then 10 nS),
so being able to use this for unlocking will double the best-case
performance of an SMP lock in the non-contending case, and triple it
(or even better) in the contending case.
So using a procedure is perfectly acceptable. It really is
a no-brainer. You also really, really want to use non-locked
instructions for unlocking and for recursive locks if you can.
-Matt
Matthew Dillon
<dillon@backplane.com>
:----- Begin Included Message -----
:Date: Wed, 24 May 2000 19:08:00 -0700
:From: Matthew Dillon <dillon@apollo.backplane.com>
:To: Chuck Paterson <cp@bsdi.com>
:Subject: Re: Preemptive kernel on older X86 hardware
:cc: Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG
:
: We've had very good luck encapsulating our MP lock code in real
: honest-to-god subroutines rather then trying to make them inline
: macros.
:
: On intel anyway, subroutine calls are *cheap*, especially compared
: to the overhead of a locked instruction or even an L1 cache miss.
:
: It's a no-brainer.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250345.UAA78676>