From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 7 12:26:37 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2BF116A4CE for ; Mon, 7 Jun 2004 12:26:36 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC63D43D4C for ; Mon, 7 Jun 2004 12:26:36 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14897 invoked from network); 7 Jun 2004 12:26:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 7 Jun 2004 12:26:34 -0000 Received: from slimer.baldwin.cx (slimer.baldwin.cx [192.168.0.16]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i57CQQFI002358; Mon, 7 Jun 2004 08:26:26 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-hackers@FreeBSD.org Date: Mon, 7 Jun 2004 08:27:21 -0400 User-Agent: KMail/1.6 References: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> In-Reply-To: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406070827.21333.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Robert Watson cc: Ali Niknam Subject: Re: FreeBSD 5.2.1: Mutex/Spinlock starvation? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 12:26:37 -0000 On Saturday 05 June 2004 04:55 pm, Ali Niknam wrote: > Hi Robert, > > As promised my findings regarding the changes; just came home after a night > of trying and praying :) > > > Actually, by default, most mutexes in the system are sleep mutexes, so > > they sleep on contention rather than spinning. In some cases, this > > actually hurts more than spinning, because if the mutex is released > > quickly by the holder, then you pay the context switches which cost > > more than spinning for the short period of time. > > > > You might want to try adding "options ADAPTIVE_MUTEXES" to your kernel > > configuration, which will cause mutexes to spin briefly on SMP systems > > before sleeping, and has been observed to improve performance quite a > > bit. > > I tried this; this helps performance a lot, here are the findings: > - under all conditions turning on HTT helps a *lot* (which is logical i > think) > - under non killing load (killing load = load where server would have > crashed without this option) it performs much much better > - under killing load it performs a lot better, up until a certain level: > - a new killing level: from this point onward basically the same thing > happens as before.. > > What i'm guessing is that probably this new killing level occurs when load > is so high that the spins 'adapt' into blocks. From your description above > I understand that there's a certain timeout when 'spinning' mutexes turn > into 'blocking'/'sleeping' mutexes. Is there a way to set this timeout ? I > would very much like to try out what would happen if one would set this > timeout to a quite high value. There isn't a timeout. Rather, the lock spins so long as the current owning thread is executing on another CPU. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org