On Tue, 24 Apr 2007 21:37:47 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> Andrew Morton wrote:
> > Any which enable CONFIG_DEBUG_PREEMPT...
> >
>
> Hm. Normally smp_processor_id() CSEs nicely, so it isn't generally
> necessary to do it manually.
For all architectures?
> Not sure what CONFIG_DEBUG_PREEMPT will do
> to it.
#ifdef CONFIG_DEBUG_PREEMPT
extern unsigned int debug_smp_processor_id(void);
# define smp_processor_id() debug_smp_processor_id()
#else
# define smp_processor_id() raw_smp_processor_id()
#endif
We could perhaps mark debug_smp_processor_id() as pure or const or whatever
the trick is to say it doesn't need to be reevaluated. That would usually
be OK, because as long as preempt is disabled that _is_ how it works,
however code might do:
preempt_disable();
smp_processor_id();
preempt_enable();
<preempt or schedule()>
preempt_disable();
smp_processor_id();
preempt_enable();
and caching the value would be wrong.
hm. If "smp_processor_id() CSEs nicely", what prevents the compiler from
making the same mistake? IOW, what are the barriers for CSE? Function
calls?
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
