Messages in this thread | | | Date | Wed, 27 May 2009 13:46:58 -0400 | From | cl@linux-fo ... | Subject | [my_cpu_ptr 0/5] Introduce my_cpu_ptr/__my_cpu_ptr |
| |
The problem with per_cpu_ptr(x, smp_processor_id) is that it requires an array lookup to find the offset for the cpu. Processors typically have the offset for the current cpu area already in some kind of (arch dependent) efficiently accessible register or memory location.
We can use the per cpu offset instead of doing the array lookup to speed up the determination of the address of the percpu variable. This is particularly significant because these lookups occur in performance critical paths of the core kernel.
This optimization is a prerequiste to the introduction of per processor atomic operations for the core code. Atomic per processor operations implicitly do the offset calculation to the current per cpu area in a single instruction. The locations touched by this patchset are potential candidates for atomic per cpu operations.
The patchset does not cover arch code nor exotic cases where the current cpu is determined before the call into a function.
--
| |