Messages in this thread | | | Subject | Re: per-cpu operation madness vs validation | From | Peter Zijlstra <> | Date | Wed, 27 Jul 2011 15:01:17 +0200 |
| |
On Wed, 2011-07-27 at 14:11 +0200, Peter Zijlstra wrote:
> Hence my suggestion to do something like: > > struct foo { > percpu_lock_t lock; > int a; > int b; > } > > DEFINE_PER_CPU(struct foo, foo); > > percpu_lock(&foo.lock); > __this_cpu_inc(foo.a); > __this_cpu_inc(foo.b); > percpu_unlock(&foo.lock); > > That would get us (aside from a shitload of work to make it so): > > - clear boundaries of where the data structure atomicy lie > - validation, for if the above piece of code was also ran from IRQ > context we could get lockdep complaining about IRQ unsafe locks used > from IRQ context. > > Now for !-rt percpu_lock will not emit more than > preempt_disable/local_bh_disable/local_irq_disable, depending on what > variant is used, and the data type percpu_lock_t would be empty (except > when enabling lockdep of course). > > 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.
Also, I think we can mostly deprecate preempt_disable, local_bh_disable and local_irq_disable when we have percpu_lock_t, or is local_lock_t a better name?
| |