On Fri, 30 May 2008, Peter Zijlstra wrote: > For -rt add the spinlock and thereby guarantee mutual exclusion in the > face of preemption. This of course does mean reduced performance due to > remote cpu memory accesses, but otherwise the allocator (slub in this > case) would have far too large preempt-off sections. Hmmm.. So you want to lock and then be migrated while still accessing per cpu data of the earlier cpu? That breaks a lot of assumptions in the main kernel and would make cpu ops and local_t etc impossible because these rely on atomicity vs. interrupt vs atomicity vs access from other cpus. If you modify the per cpu data of one processor from multiple processor concurrently then races will result. If you want to do it that way then local_t and cpu_ops would not work. The cpu ops scheme is to not rely on any locking and still guarantee access to the correct per cpu area regardless of whether the process is rescheduled or not simply by the fact that the per cpu address calculation and the RMW cycle are one instruction. Maybe we need to have different types of per cpu areas for both approaches? Your requires a spinlock to be taken for a section of the percpu space. -- 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
