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 <[EMAIL PROTECTED]> 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
