From owner-freebsd-arch Wed May 24 21: 1:37 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id 0E28837BDCA for ; Wed, 24 May 2000 21:01:35 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@[127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id WAA17540; Wed, 24 May 2000 22:01:18 -0600 (MDT) Message-Id: <200005250401.WAA17540@berserker.bsdi.com> To: Matthew Dillon Cc: Terry Lambert , arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware From: Chuck Paterson Date: Wed, 24 May 2000 22:01:18 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } 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. This means that you use 17ns and on a UP machine with and non locked cmpxchg the time is going to propably more than double. I still content that this is the single most important thing to make fast in the uncontended case and everybit counts. Actually this can be decided by experimentation when the thing is running. It's not like a fundamental design decision. } A locked instruction with the second cpu doing a contending locked } instruction costs 322 nS on EACH cpu. <<<<<<<<<<<<< VERY EXPENSIVE With a non spin mutex 322ns just doesn't matter because when this happens we are going to do a context switch. } 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. If we have contention on a unlock then once again speed doesn't matter much we are going to being mucking about putting something on the run queueu. If the task we put on the run queue is high priority then we will be switching to it. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message