On Tue, 10 Jun 2008, Rusty Russell wrote:

quoted text
> > > Yes, this should be fixed.  I thought i386 had optimized versions
> > > pre-merge, but I was wrong (%gs for per-cpu came later, and noone cleaned
> > > up these naive versions).  Did you want me to write them?
> >
> > How can that be fixed? You have no atomic instruction that calculates the
> > per cpu address in one go.
> 
> Huh?  "incl %fs:varname" does exactly this.

Right that is what the cpu alloc patches do. So you could implement 
cpu_local_inc on top of some of the cpu alloc patches.

quoted text
> > And as long as that is the case you need to 
> > disable preempt. Otherwise you may increment the per cpu variable of
> > another processor because the process was rescheduled after the address
> > was calculated but before the increment was done.
> 
> But of course, that is not a problem.  You make local_t an atomic_t, and then 
> it doesn't matter which CPU you incremented.

But then the whole point of local_t is gone. Why not use atomic_t in the 
first place?
 
quoted text
> By definition if the caller cared, they would have had premption disabled.

There are numerous instances where the caller does not care about 
preemption. Its just important that one per cpu counter is increment in 
the least intrusive way. See f.e. the VM event counters.

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