From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 8 01:15:45 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B916016A4CE; Tue, 8 Jun 2004 01:15:44 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.12.11/8.12.11) with ESMTP id i581Fi2q023262; Mon, 7 Jun 2004 21:15:44 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.12.11/8.12.11/Submit) id i581FhHF023261; Mon, 7 Jun 2004 21:15:43 -0400 (EDT) (envelope-from green) Date: Mon, 7 Jun 2004 21:15:43 -0400 From: Brian Feldman To: Ali Niknam Message-ID: <20040608011543.GC23083@green.homeunix.org> References: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00da01c44b3f$74d3d8c0$0400a8c0@redguy> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: Robert Watson 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: Tue, 08 Jun 2004 01:15:45 -0000 On Sat, Jun 05, 2004 at 10:55:31PM +0200, Ali Niknam wrote: > 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.. Something is happening which should not be at a much more fundamental level. Something is going on to cause everything to block in Giant. That could be some exceptionally-long operation that executes, holding Giant, without andy context switches. In general, this is really what you would call a "deadlock," but at least you can recover from it. If the system is totally unresponsive to your input, is it still working from the standpoint of the users on it? Are there strange syslog messages? Can you watch the history of sysctl vm.vmtotal, sysctl vm.zone, and vmstat -m to see if it's a memory starvation issue? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\