From owner-cvs-src@FreeBSD.ORG Tue Oct 16 22:21:06 2007 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB1A16A417; Tue, 16 Oct 2007 22:21:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 5FC4F13C459; Tue, 16 Oct 2007 22:21:06 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1D1301A4D7C; Tue, 16 Oct 2007 15:21:06 -0700 (PDT) Date: Tue, 16 Oct 2007 15:21:06 -0700 From: Alfred Perlstein To: Kris Kennaway Message-ID: <20071016222106.GF31826@elvis.mu.org> References: <200710160736.l9G7a3oI087966@repoman.freebsd.org> <471480AB.7090500@FreeBSD.org> <4714F750.9010804@freebsd.org> <47150841.2080306@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47150841.2080306@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Jason Evans , cvs-all@FreeBSD.org, David Xu Subject: Re: cvs commit: src/lib/libthr/thread thr_pspinlock.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Oct 2007 22:21:06 -0000 * Kris Kennaway [071016 11:51] wrote: > Jason Evans wrote: > >Kris Kennaway wrote: > >>David Xu wrote: > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> lib/libthr/thread thr_pspinlock.c Log: > >>> Reverse the logic of UP and SMP. > >>> Submitted by: jasone > >>> Revision Changes Path > >>> 1.6 +1 -1 src/lib/libthr/thread/thr_pspinlock.c > >> > >>Are there any common applications that use this? > > > >It's worth mentioning that this change, although correct, does not make > >a measurable performance difference for the tests I was running when I > >found the bug. It is possible that making the spinlocks adaptive would > >help, but I didn't look into this. > > > >(I was working on malloc performance enhancements that have turned out > >very nicely, but in the end I had to switch to hand-rolled "spin" > >mutexes that eventually convert to blocking, in order to avoid the > >possibility of unrecoverable priority inversion.) > > BTW I am looking at adding a non-portable (sort of) pthread mutex type > that spins for a while when the lock is held, before blocking. This is > sometimes good for performance when the pthread mutex is highly > contended but held for short periods of time, and in fact Linux has such > a mutex that is used by mysql with performance benefits. > > The real fix would be to make them adaptive in the same way as kernel > mutexes (spin as long as the lock holder is running), but there is > currently no easy way for userland to peer into the kernel to check the > other thread's state. Soon.... :D -- - Alfred Perlstein