Lines Matching full:are

8 this_cpu operations are a way of optimizing access to per cpu
18 This means that there are no atomicity issues between the calculation of
24 Read-modify-write operations are of particular interest. Frequently
32 synchronization is not necessary since we are dealing with per cpu
34 processor should be accessing that variable and therefore there are no
37 Please note that accesses by remote processors to a per cpu area are
45 are defined. These operations can be used without worrying about
115 the value of the individual counters for each processor are
119 Per cpu variables are used for performance reasons. Bouncing cache
149 preemptible code are addressed by raw_cpu_ptr(), but such use cases need
150 to handle cases where two different CPUs are accessing the same per cpu
151 variable, which might well be that of a third CPU. These use cases are
199 Operations on these fields are straightforward::
230 this_cpu ops are interrupt safe. Some architectures do not support
233 that are guaranteed to be atomic and then re-enable interrupts. Doing
234 so is expensive. If there are other reasons why the scheduler cannot
235 change the processor we are executing on then there is no reason to
237 are provided.
241 and the scheduler cannot preempt, then they are safe. If any interrupts
278 this_cpu_read() and friends are used.
284 Per cpu data structures are designed to be used by one cpu exclusively.
285 If you use the variables as intended, this_cpu_ops() are guaranteed to
288 There are special cases where you might need to access per cpu data
295 Remote write accesses to percpu data structures are highly discouraged
307 This makes it explicit that we are getting ready to access a percpu
317 Remote access are typically only for reading the status of another cpus
339 data within the same cache line are avoided. Also costly synchronization
340 may be necessary. IPIs are generally recommended in such scenarios instead
343 Even in cases where the remote writes are rare, please bear in