Date: Tue, 5 Jun 2007 20:00:51 -0700 (PDT) From: Jeff Roberson <jroberson@chesapeake.net> To: Bruce Evans <brde@optusnet.com.au> Cc: src-committers@FreeBSD.org, John Baldwin <jhb@FreeBSD.org>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Attilio Rao <attilio@FreeBSD.org>, Kostik Belousov <kostikbel@gmail.com> Subject: Re: cvs commit: src/sys/kern kern_mutex.c Message-ID: <20070605195839.I606@10.0.0.1> In-Reply-To: <20070606094354.E51708@delplex.bde.org> References: <200706051420.l55EKEih018925@repoman.freebsd.org> <3bbf2fe10706050829o2d756a4cu22f98cf11c01f5e4@mail.gmail.com> <3bbf2fe10706050843x5aaafaafy284e339791bcfe42@mail.gmail.com> <200706051230.21242.jhb@freebsd.org> <20070606094354.E51708@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <attilio@freebsd.org>: >>>> 2007/6/5, Bruce Evans <brde@optusnet.com.au>: >>>>> >>>>> 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070605195839.I606>