Skip site navigation (1)Skip section navigation (2)
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>