Re: [linux-audio-dev] Re: [announce] [patch] Voluntary Kernel Preemption Patch

[Scott Wood]

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@xxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/