29 Jul
2004
29 Jul
'04
5:33 p.m.
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:
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
* Scott Wood <scott(a)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).