From owner-freebsd-arch Wed May 24 20:37: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 7AD0237BDCA for ; Wed, 24 May 2000 20:37:34 -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 VAA17273; Wed, 24 May 2000 21:37:31 -0600 (MDT) Message-Id: <200005250337.VAA17273@berserker.bsdi.com> To: Matthew Dillon Cc: arch@freebsd.org Subject: Re: Short summary From: Chuck Paterson Date: Wed, 24 May 2000 21:37:31 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG } } Ouch, having the contending cpu actually do a locked write } to the lock (i.e. cache line) held by another cpu is really, } really slow. Both processors will eat the full overhead of } the hardware cache coherency protocol - It's about 3 times } as expensive as a contended lock without the ping-pong writing } and about twice as expensive as a non-contending lock, } and recursive locks using this model will be about 5x as expensive } even in the best case. } } If there is any way to avoid this, I would avoid this. } I don't believe so. The mutex release has to be a locked operation so we can detect if the mutex is just going contended. Also remember that when this happens the other cpu isn't involved when we do the unlock. The other cpu is running some other process, or actually may be the cpu releasing the lock. We don't have the two processors banging on the cache line at the same time like occurs with spin locks. When we believe recursion is likely we can do the checking for recursion up front. We do mess with the recursion count without locks. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message