From owner-freebsd-current@FreeBSD.ORG Thu May 6 12:24:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F8716A4CE; Thu, 6 May 2004 12:24:51 -0700 (PDT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D73E843D5F; Thu, 6 May 2004 12:24:50 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i46JOk5v003734; Fri, 7 May 2004 05:24:46 +1000 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i46JOiHW017101; Fri, 7 May 2004 05:24:45 +1000 Date: Fri, 7 May 2004 05:24:43 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin In-Reply-To: <200405061411.27216.jhb@FreeBSD.org> Message-ID: <20040507050827.O22484@gamplex.bde.org> References: <20040506184749.R19447@gamplex.bde.org> <200405061411.27216.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Gerrit Nagelhout cc: 'Andrew Gallatin' Subject: Re: 4.7 vs 5.2.1 SMP/UP bridging performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 19:24:52 -0000 On Thu, 6 May 2004, John Baldwin wrote: > On Thursday 06 May 2004 06:18 am, Bruce Evans wrote: > > On Wed, 5 May 2004, Gerrit Nagelhout wrote: > > > Andrew Gallatin wrote: > > > > If its really safe to remove the xchg* from non-SMP atomic_store_rel*, > > > > then I think you should do it. Of course, that still leaves mutexes > > > > as very expensive on SMP (253 cycles on the 2.53GHz from above). > > > > See my other reply [1 memory barrier but not 2 seems to be needed for > > each lock/unlock pair in the !SMP case, and the xchgl accidentally (?) > > provides it; perhaps [lms]fence would give a faster memory barrier]. > > More ideas on this: > > ... > > - jhb once tried changing mtx_lolock_spin(mtx)/mtx_unlock_spin(mtx) to > > crticial_enter()/critical_exit(). This didn't work because it broke > > mtx_assert(). It might also not work because it removes the memory > > barrier. criticial_enter() only has the very weak memory barrier in > > disable_intr() on i386's. > > That was only for the UP case, in which case you don't need the membar's. A > single CPU always consistently sees what it has written. The only case when Er, see my other reply about why one might be needed. Actually, none is in my example. Interrupts aren't a problem because both hardware interrupts and the iret instruction are serializing. > it doesn't is for memory that can be written to by device DMA, and that > doesn't apply to kernel data structures, esp. not to ones for scheduling, > etc. There are also cases from using the SSE2 movnt* instructions. These act a bit like DMA and require sfence. Bruce