Re: [patch 04/41] cpu ops: Core piece for generic atomic per cpu operations

Christoph Lameter
2008-06-09T23:54:20Z

On Tue, 10 Jun 2008, Rusty Russell wrote:

> > > 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.

> > 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?

> 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.