Date: Wed, 24 May 2000 21:37:31 -0600 From: Chuck Paterson <cp@bsdi.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Short summary Message-ID: <200005250337.VAA17273@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
} } 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250337.VAA17273>