On Wed, 4 Jun 2008, Mike Travis wrote: > 0000000000000013 <test_local_inc>: > 13: 55 push %rbp > 14: 65 48 8b 05 00 00 00 mov %gs:0(%rip),%rax # 1c <test_local_inc+0x9> > 1b: 00 > 1c: 48 89 e5 mov %rsp,%rbp > 1f: 48 ff 04 07 incq (%rdi,%rax,1) > 23: c9 leaveq > 24: c3 retq Note also that the address calculation occurs before the incq. That is why disabling preemption is required otherwise the processor may change between the determination of the per cpu area address and the increment. The local_t operations could be modified to avoid the preemption issues with the zero based patches applied. Then there would still be the inflexbility of not being able to increment an arbitrary variable. I think it is also bad to treat a per cpu variable like an atomic. Its not truly atomic nor are strictly atomic accesses used. It is fine to use regular operations on the per cpu variable provided one has either disabled preemption or interrupts. The per cpu atomic wrt interrupt ops are only useful when preemption and/or interrupts are off. -- 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
