On Sat, 2 Aug 2014, Pranith Kumar wrote: > +Remote access to per cpu data > +------------------------------ > + > +Per cpu data structures are designed to be used by one cpu exclusively. > +If you use the variables as intended, this_cpu_ops() are guaranteed to > +be "atomic" as no other CPU has access to these data structures. In this > +context, a remote access means an access to a per cpu data structure > +from a CPU without using the this_cpu_* operations. Access to the per cpu is valid in preempt safe sections by using this_cpu_ptr() to calculate a basic addresa and then using this pointer modifying per cpu variables. > +There are special cases where you might need to access per cpu data > +structures remotely. One such case is to perform maintenance tasks of > +idle CPUs without having to wake them up using IPIs for power saving > +purposes. It is usually safe to do a remote read access and that is I am not sure what the "maintenance tasks" sentence is doing in here. This looks like we are discussing read access. Maintenance implies write. Regular remote access is a read acess to summarize counters and that should be discussed first. > +frequently done to summarize counters. Remote write access is the one > +which is problematic. Remote write accesses to per cpu data structures > +are highly discouraged until absolutely necessary. Please consider using > +an IPI to wake up the remote CPU and perform the update to its per cpu > +area. > + > +To access per-cpu data structure remotely, you need to convert the > +per-cpu offset to a pointer using this_cpu_ptr(). > + > + DEFINE_PER_CPU(struct data, datap); > + struct data *p = per_cpu(&datap, cpu); > + > +p can now be passed to another CPU to be updated remotely. Again this is not the typical way of doing things. Remote cpus usually use per_cpu_ptr(percpustruct, cpu) to calculate the adress of a variable in a remote percpu areas. The approach presented here is not recommended because it implies the adress of a local percpu struct being pushed to other cpus which may not be aware of the nature of the storage area that they access. percpu_ptr() makes it clear in a loop or so that we are performing remote percpu data access now. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
