Re: per-cpu operation madness vs validation

[Christoph Lameter]

On Wed, 27 Jul 2011, Peter Zijlstra wrote:

> > Possibly we could reduce all this percpu madness back to one form
> > (__this_cpu_*) and require that when used a lock of the percpu_lock_t is
> > taken.
>
> get_cpu_var()/put_cpu_var() were supposed to provide such delineation as
> well, but you've been actively destroying things like that with the
> recent per-cpu work.

The per cpu work is *not* focused on sections that access per cpu data, so
how could it destroy that? Nothing is changed there so far. The this_cpu
ops are introducing per cpu atomic operations that are safe and cheap
regardless of the execution context. The primary initial motivation was
incrementing per cpu counters without having to disabling interrupts
and/or preemption and it grew from there.

The atomic per cpu operations (like the this_cpu_cmpxchg) allow the
construction of cheap sections that would satisfy your goals too (with
some work and the use of transaction ids instead of locking). See the slub
fastpath f.e.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/