From owner-cvs-all@FreeBSD.ORG Tue Oct 16 18:51:46 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B5016A417; Tue, 16 Oct 2007 18:51:46 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx1.freebsd.org (Postfix) with ESMTP id 7614F13C4B5; Tue, 16 Oct 2007 18:51:45 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47150841.2080306@FreeBSD.org> Date: Tue, 16 Oct 2007 20:51:45 +0200 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jason Evans References: <200710160736.l9G7a3oI087966@repoman.freebsd.org> <471480AB.7090500@FreeBSD.org> <4714F750.9010804@freebsd.org> In-Reply-To: <4714F750.9010804@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, David Xu , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libthr/thread thr_pspinlock.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2007 18:51:46 -0000 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. Kris