lkml.org 
[lkml]   [2014]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 1/1] doc: this_cpu_ops.txt: clarify remote accesses of per cpu areas
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.


\
 
 \ /
  Last update: 2014-08-04 17:41    [W:0.058 / U:0.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site