Lines Matching +full:y +full:- +full:offset

14 this_cpu operations add a per cpu variable offset to the processor
19 the offset and the operation on the data. Therefore it is not
24 Read-modify-write operations are of particular interest. Frequently
65 ------------------------------------
101 	int *y;
105 	y = per_cpu_ptr(&x, cpu);
106 	(*y)++;
128 ------------------
132 	y = this_cpu_ptr(&x)
134 Takes the offset of a per cpu variable (&x !) and returns the address
138 available. Instead, the offset of the local per cpu area is simply
139 added to the per cpu offset.
144 is re-enabled this pointer is usually no longer useful since it may
149 -----------------------------
153 code. Offsets cannot be directly dereferenced. The offset must be
172 &x and hence p is the *offset* of a per cpu variable. this_cpu_ptr()
173 takes the offset of a per cpu variable which makes this look a bit
178 --------------------------------------------
196 If we have an offset to struct s::
200 	this_cpu_dec(ps->m);
202 	z = this_cpu_inc_return(ps->n);
212 	pp->m--;
214 	z = pp->n++;
218 ------------------------
223 that are guaranteed to be atomic and then re-enable interrupts. Doing
252 Will increment x and will not fall-back to code that disables
254 address relocation and a Read-Modify-Write operation in the same
258 &this_cpu_ptr(pp)->n vs this_cpu_ptr(&pp->n)
259 --------------------------------------------
261 The first operation takes the offset and forms an address and then
262 adds the offset of the n field. This may result in two add
272 ------------------------------
289 To access per-cpu data structure remotely, typically the per_cpu_ptr()
300 You can also do the following to convert the datap offset to an address::
313 share a cache-line but the relaxed synchronization is applied to
314 only one process updating the cache-line.