Messages in this thread | | | Date | Thu, 18 Jun 2009 10:08:50 +0900 | From | Tejun Heo <> | Subject | Re: [this_cpu_xx 01/11] Introduce this_cpu_ptr() and generic this_cpu_* operations |
| |
Hello,
Christoph Lameter wrote: > On Wed, 17 Jun 2009, Tejun Heo wrote: >> Please note that this can also happen between addition or other >> modifying ops and cause incorrect result. > > Per cpu operations are only safe for the current processor. One issue > there may be that the store after rescheduling may not occur to the > current processors per cpu instance but the prior cpu. At that point > another thread may be running on the prior cpu and be disturbed like you > point out. So it needs a preempt disable there too.
Yeap, to summarize, the problem is that the address determination and the actual memory write aren't atomic with respect to preeamption.
>> Also, these macros depricate percpu_OP() macros, right? > > They are different. percpu_OP() macros require a percpu variable name > to be passed. > > this_cpu_* macros require a reference to a variable in a > structure allocated with the new per cpu allocator. > > It is possible to simply pass the full variable name of a percpu variable > to this_cpu_* macros. See the patch of the vm statistics handling. > > It uses > > per_cpu_var(per_cpu_name_without_prefix) > > to generate the full name.
Yeap, I guess it's about time to ressurect Rusty's drop-per_cpu_ prefix patch; then, we can truly handle static and dynamic variables in the same manner.
Thanks.
-- tejun
| |