Re: [PATCH v4 1/1] doc: this_cpu_ops.txt: clarify remote accesses of per cpu areas

[Christoph Lameter]

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-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/