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. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
