lkml.org 
[lkml]   [2011]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: per-cpu operation madness vs validation
From
Date
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?


\
 
 \ /
  Last update: 2011-07-27 15:03    [W:0.114 / U:0.036 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site