|| ||firstname.lastname@example.org |
|| ||email@example.com |
|| ||[my_cpu_ptr 0/5] Introduce my_cpu_ptr/__my_cpu_ptr |
|| ||Wed, 27 May 2009 13:46:58 -0400|
|| ||Tejun Heo <firstname.lastname@example.org>|
|| ||Article, Thread
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/