From owner-freebsd-arch Wed May 24 20:45:40 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DD31C37BDCA for ; Wed, 24 May 2000 20:45:37 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA78676; Wed, 24 May 2000 20:45:34 -0700 (PDT) (envelope-from dillon) Date: Wed, 24 May 2000 20:45:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200005250345.UAA78676@apollo.backplane.com> To: Chuck Paterson Cc: Terry Lambert , arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware References: <200005250228.UAA16415@berserker.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : 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 :----- Begin Included Message ----- :Date: Wed, 24 May 2000 19:08:00 -0700 :From: Matthew Dillon :To: Chuck Paterson :Subject: Re: Preemptive kernel on older X86 hardware :cc: Terry Lambert , 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