From owner-cvs-all@FreeBSD.ORG Wed Jun 6 00:03:41 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB21F16A468; Wed, 6 Jun 2007 00:03:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 495BE13C487; Wed, 6 Jun 2007 00:03:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l5603Z0T018975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Jun 2007 10:03:39 +1000 Date: Wed, 6 Jun 2007 10:03:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: John Baldwin In-Reply-To: <200706051230.21242.jhb@freebsd.org> Message-ID: <20070606094354.E51708@delplex.bde.org> References: <200706051420.l55EKEih018925@repoman.freebsd.org> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com> <200706051230.21242.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, Attilio Rao , Bruce Evans , Kostik Belousov Subject: Re: cvs commit: src/sys/kern kern_mutex.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: Wed, 06 Jun 2007 00:03:41 -0000 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. 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