From owner-cvs-src@FreeBSD.ORG Tue Nov 9 21:34:27 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4954616A4CE; Tue, 9 Nov 2004 21:34:27 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A834143D3F; Tue, 9 Nov 2004 21:34:26 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iA9LXHov061665; Tue, 9 Nov 2004 16:33:17 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iA9LXHPZ061662; Tue, 9 Nov 2004 21:33:17 GMT (envelope-from robert@fledge.watson.org) Date: Tue, 9 Nov 2004 21:33:17 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <4191062A.6090009@elischer.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: src-committers@FreeBSD.org cc: John Baldwin cc: Alan Cox cc: cvs-src@FreeBSD.org cc: Mike Silbersack cc: cvs-all@FreeBSD.org cc: Stephan Uphoff Subject: Re: cvs commit: src/sys/i386/i386 pmap.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2004 21:34:27 -0000 On Tue, 9 Nov 2004, Julian Elischer wrote: > >Assuming that these changes are correct, and pass whatever tests people > >have in mind, this would be a very strong merge candidate for performance > >reasons. The difference is visible in packet send tests from user space > >as a percentage or two improvement on UP on my P4, although it's a litte > >hard to tell due to the noise. > > > Can you explain why a spin mutex is more expensive than a sleep mutex (I > assume this is uncontested)? A sleep mutex involves only an atomic acquire. A spin mutex also disables interrupts. The reasons for this are documented extensively in various books on the topic, but my personal favorite is the UNIX Systems for Modern Architectures version. Basically, spin locks are the preferred way to synchronize with interrupt handlers, and you don't want an interrupt handler to spin when it attempts to preempt code holding the spin lock it wants to acquire. The easiest way to avoid this is to disable interrupts while holding the spin lock. Various critical section optimizations are presumably applicable here, as with other uses of critical seections. The interrupt disable/enable instructions are especially expensive on the P4, which shows up clearly in the spin lock micro-benchmarks. Ideally, you should see the cost of a spin lock being the cost of a sleep mutex plus the cost of a critical section, minus some fudge due to pipe-lining. The odd case we've been discussing was one where this was clearly not the case: an extra one hundred cycles appeared as a result of a cmpxchg which is implemented via a locked instruction on the P4. So it turns out, elementary school arithmetic was actually useful :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research