On Tue, 24 Apr 2007 21:37:47 -0700 Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
