On Fri, 2008-05-30 at 11:11 -0700, Christoph Lameter wrote: > 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. Yes, I get that, but for instance kmem_cache_cpu usage would require horrible long preempt off sections, hence we add a lock and manage consistency using that lock instead of strict per-cpu and preempt disable. -- 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
