On Fri, 30 May 2008, Ingo Molnar wrote: > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > What this does is make a strong connection between data and > > concurrency control. Your proposed scheme weakens the > > data<->concurrency relation instead of making it stronger. > > and that's not just an issue for -rt but also for general kernel > maintainability: opaque APIs weaken our data structures because it's not > apparent what is done exactly why. In that sense a > spin_lock(&data->lock) is as clear as it gets. The intent of these CPU_OPS is to avoid synchronization by having atomic per cpu ops that do not require preempt or interrupt disable to function properly. F.e. it allows the updating of per cpu statistics without get_cpu/put_cpu or preempt_enable/disable etc etc. This should help -rt quite a bit by avoiding numerous of these things in hot vm paths. -- 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
