On Thu, 17 Jul 2014, Pranith Kumar wrote: > > The use of atomic_t implies a remote write operation to a percpu area. > > > > atomic_t needs to be avoided. If data needs to be modified from multiple > > cpus then it usually does not belong into a percpu area. > > > > Yes, I think I made it pretty clear that remote accesses need to be avoided > unless absolutely necessary. But, there will be scenarios where mostly local > data will need to be have remote accesses. In such scenarios, isn't using > atomic_t better? FYI, that is how RCU code currently works. It uses atomic_t in > per cpu areas to ensure atomicity for remote accesses. The RCU code has .... ummmm... some issues with percpu usage and should not be taken as a good example. If you look at the RCU code it looks horrible with numerous barriers around remote percpu read/wrirte accesses and one wonders if that code is actually ok. > If data needs to be modified from multiple cpus only very rarely, doesn't it > make sense to use per-cpu areas? I would suggest that this should not occur. You can always "modify" remote percpu areas by generating an IPI on that cpu to make that processor update its own per cpu data. -- 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
