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
116 the value of the individual counters for each processor are
120 Per cpu variables are used for performance reasons. Bouncing cache
190 Operations on these fields are straightforward::
221 this_cpu ops are interrupt safe. Some architectures do not support
224 that are guaranteed to be atomic and then re-enable interrupts. Doing
225 so is expensive. If there are other reasons why the scheduler cannot
226 change the processor we are executing on then there is no reason to
228 are provided.
232 and the scheduler cannot preempt, then they are safe. If any interrupts
270 this_cpu_read() and friends are used.
276 Per cpu data structures are designed to be used by one cpu exclusively.
277 If you use the variables as intended, this_cpu_ops() are guaranteed to
280 There are special cases where you might need to access per cpu data
287 Remote write accesses to percpu data structures are highly discouraged
299 This makes it explicit that we are getting ready to access a percpu
309 Remote access are typically only for reading the status of another cpus
331 data within the same cache line are avoided. Also costly synchronization
332 may be necessary. IPIs are generally recommended in such scenarios instead
335 Even in cases where the remote writes are rare, please bear in