On Thu, 2011-08-25 at 14:19 -0500, Christoph Lameter wrote: > On Thu, 25 Aug 2011, Peter Zijlstra wrote: > > > Also, I thought this_cpu thing's were at best locally atomic. If you > > make them full blown atomic ops then even __this_cpu ops will have to be > > full atomic ops, otherwise: > > > > > > CPU0 CPU(1) > > > > this_cpu_inc(&foo); preempt_disable(); > > __this_cpu_inc(&foo); > > preempt_enable(); > > > > might step on each other's toes. > > They would both have their own instance of "foo". per cpu atomicity is > only one requirement of this_cpu_ops. The other is the ability to relocate > accesses relative to the current per cpu area. Ah, but not if the this_cpu_inc() thing ends up being more than a single instruction, then you have preemption/migration windows. Only when LL/SC can deal with SC having a different EA from the LL and supports a big enough offset could this possibly work. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
