Re: [PATCH v2 1/1] doc: Add remote CPU access details and others to this_cpu_ops.txt

[Christoph Lameter]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/