Re: [PATCH] local_t : Documentation

Andrew Morton <[email protected]>
Newsgroups gmane.linux.systemtap,gmane.linux.kernel,gmane.linux.kernel.tracing
Message-ID <[email protected]>
On Tue, 9 Jan 2007 17:06:16 -0500
Mathieu Desnoyers <[email protected]> wrote:

> * Andrew Morton ([email protected]) wrote:
> > On Mon, 8 Jan 2007 22:14:46 -0500
> > Mathieu Desnoyers <[email protected]> wrote:
> > 
> > > +* How to use local atomic operations
> > > +
> > > +#include <linux/percpu.h>
> > > +#include <asm/local.h>
> > > +
> > > +static DEFINE_PER_CPU(local_t, counters) = LOCAL_INIT(0);
> > > +
> > > +
> > > +* Counting
> > > +
> > > +In preemptible context, use get_cpu_var() and put_cpu_var() around local atomic
> > > +operations : it makes sure that preemption is disabled around write access to
> > > +the per cpu variable. For instance :
> > > +
> > > +	local_inc(&get_cpu_var(counters));
> > > +	put_cpu_var(counters);
> > 
> > Confused.  The whole point behind local_t is that we can do
> > atomic-wrt-interrupts inc and dec on them.
> > 
> > Consequently, as atomic-wrt-interrupts means atomic-wrt-preemption, there
> > is no need to do a preempt_disable() around local_inc() and local_dec().
> > 
> 
> Hi Andrew,
> 
> Not exactly : the increment operation is atomic, but not the selection of the
> local variable. local_inc(&__get_cpu_var()) implies the following sequence 
> of operations :
> 
> 1 - Get the variable copy corresponding to the currently running CPU.
> 2 - atomically increment the variable.
> 
> It would be wrong to be scheduled on another CPU between 1 and 2, because the
> atomic increment should only be done by the CPU "owner" of the local variable,
> as the local atomic increment is not atomic wrt other CPUs.
> 

doh.  I knew that.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.