On Thu, Jul 10, 2014 at 4:55 PM, Christoph Lameter <cl@xxxxxxxxxx> wrote: > On Thu, 10 Jul 2014, Pranith Kumar wrote: > >> > Per cpu data structures are for the use of one cpu exclusively. If you use >> > the variable as intended then there is no atomic_t required. If you want >> > to update the percpu variable from other processors then atomic_t is >> > required. But then this is not a proper percpu variable anymroe. >> > >> >> That also makes using barriers while updating such variables >> meaningless I guess? like > > Correct. I understand one of the advantage of using these per cpu variables is avoiding disabling interrupts. But what happens when this cpu is preempted? The new processor will be working on the other cpu variables, but without barriers will it see the latest values? > >> >> struct data *p = this_cpu_ptr(&datap); >> > >> > This converts the offset into an address that can be generally used as >> > a pointer (but no longer with this_cpu operations). >> > >> >> So we can pass around this pointer to other cpus but not the previous >> __percpu pointer? > > You can pass this pointer around to other cpus. Caveat: the other cpus > will be accessing the percpu data from another cpu if the actually use > this pointer. Not recommended. > > A __percpu offset (dont call it pointer) is always relative to the current > cpu. So if the offset is used then the instance of the percpu variable for > the current cpu is used and not the instance for another processor. If you > pass the offset to other processors then this_cpu_ptr() will create the > address for the currrent instance and this_cpu ops will always refer to > the instance associated with the currently executing processor. > > Use of __percpu offsets is recommended. OK. > >> I think adding this information to the documentation would be a great >> idea. Especially the "__percpu" annotation. Is it ok if I try? > > Sure. But there is already some documentation in > linux/Documentation/this_cpu_ops.txt. > -- Pranith _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
