From owner-cvs-src@FreeBSD.ORG Wed Jun 6 03:01:10 2007 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E615F16A421; Wed, 6 Jun 2007 03:01:10 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 88B1113C469; Wed, 6 Jun 2007 03:01:10 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.101] (c-71-231-138-78.hsd1.or.comcast.net [71.231.138.78]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id l56317sf096831 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 5 Jun 2007 23:01:08 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 5 Jun 2007 20:00:51 -0700 (PDT) From: Jeff Roberson X-X-Sender: jroberson@10.0.0.1 To: Bruce Evans In-Reply-To: <20070606094354.E51708@delplex.bde.org> Message-ID: <20070605195839.I606@10.0.0.1> References: <200706051420.l55EKEih018925@repoman.freebsd.org> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com> <200706051230.21242.jhb@freebsd.org> <20070606094354.E51708@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@FreeBSD.org, John Baldwin , cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Attilio Rao , Kostik Belousov Subject: Re: cvs commit: src/sys/kern kern_mutex.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: Wed, 06 Jun 2007 03:01:11 -0000 On Wed, 6 Jun 2007, Bruce Evans wrote: > On Tue, 5 Jun 2007, John Baldwin wrote: > >> On Tuesday 05 June 2007 11:43:03 am Attilio Rao wrote: >>> 2007/6/5, Attilio Rao : >>>> 2007/6/5, Bruce Evans : >>>>> >>>>> I get a "spin lock held too long" panic during (an interrupt in?) acpi >>>>> initialization on booting non-PREEMPTION SCHED_4BSD SMP. Haven't tried >>>>> other cases. >>>> >>>> Do you have a backtrace or any other debugging stuffs available? > > No, it's on a laptop with no i/o :-). > >>> Mmm, I think I got the bug. >>> basically, in kern_mutex.c::_mtx_unlock_sleep(), in the not-preemptive >>> case what happens at some point is: >>> >>> td = curthread; >>> if (td->td_critnest > 0 || td1->td_priority >= td->td_priority) >>> return; >>> ... >> If this is the old #ifndef PREEMPTION manual preemption stuff, then just >> remove it. I've been wanting to axe it for a while, rwlocks don't do the >> manual preemption either, and if it is getting in the way it's best to just >> purge it. > > Interesting, I've been wanting to do the opposite -- axe the #ifdef > PREEMPTION in a different place, in pagezero, since non-manual preemption > doesn't actually work for SCHED_4BSD (it works for SCHED_ULE, but last > time I checked, SCHED_ULE was 7% slower for my makeworld benchmark > since it lets CPUs go idle when there is a runnable process in the > hope of a better CPU to run on becoming available). My SMP kernel > that crashes has this ifdef removed. However, the crash doesn't > seem to be caused by pgzero. You should try with kern.sched.pick_pri = 0. I have changed this to be the default recently. This weakens the preemption and speeds up some workloads. Are you still experiencing a crash with -current sources? Jeff > > Removing the manual preemption stuff in kern_mutex.c wouldn't affect > pgzero but might affect operation of the !PREEMPTION case for better > or worse. I only use !PREEMPTION on SMP. With only 1 CPU, something > like PREEMPTION is needed to get interrupts serviced as soon as possible, > which is the only reason that I want to preempt things, but with > 1 > CPU there is a good chance of a CPU being idle or going near the > scheduler soon and thus being scheduled to run interrupt handler(s) > soon. The chance increases with the number of CPUs. !PREEMPTION works > well in practice with only 2 CPUs (no noticeable interrupt latency), > at least with manual preemption in kern_mutex.c. > > Bruce >