Subject: Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch
From: Scott Wood (scott_AT_timesys.com)
Date: Thu Jul 29 2004 - 22:17:52 EEST
On Thu, Jul 29, 2004 at 11:36:26AM -0700, Bill Huey wrote:
> On Thu, Jul 29, 2004 at 08:21:10PM +0200, Ingo Molnar wrote:
> > * Scott Wood <scott_AT_timesys.com> wrote:
> > ok, i see - this makes 100% sense. I'm wondering how intrusive such an
> > all-preemptive patchset is? There are some problems with per-CPU data
> > structures on SMP. Right now holding a spinlock means one can use
> > smp_processor_id() and rely on it staying constant in the critical
> > section. With a mutex in the same place all such assumptions would
> > break. Is there some automatic way to deal with these issues (or to at
> > least detect them reliably?).
>
> Make smp_processor_id check if preempt_count() is non-zero to make sure
> that you're running within a non-preemptable critical section (scheduler
> deferred). Do the same with local_irq_* critical section by checking to
> see if interrupts are disabled. They are also non-preemptable (hardware
> defered).
There are legitimate reasons to use smp_processor_id() outside of a
non-preemptible region, though. These include debugging
printks/logging, and situations where the awareness of CPU is for
optimization rather than correctness (for example, using per-cpu data
with per-cpu locks, which are only contended if preemption occurs, or
per-cpu counters incremented with atomic operations (or where counter
accuracy is not critical)).
The detection mechanism we used in 2.4 was simply to grep for
smp_processor_id and check/fix everything manually (which is somewhat
tedious, but there aren't *too* many instances in core code, and many
uses are similar to one another).
-Scott
This archive was generated by hypermail 2b28 : Fri Jul 30 2004 - 10:35:50 EEST