RE: [RFC Patch]Use ar.kr2 for smp_processor_id

From: Luck, Tony <>
Date: 2007-02-09 05:03:54
Summarizing thread that I was sleeping through:

1) Use ar.kr2 for ...
No ... as Keith pointed out there is debug code in ivt.S to use
it to track the last few traps, and if that isn't being used it
is very handy for other debugging uses.  I won't give up the last
of these registers unless it is for some cause which is a clear and
obvious major win in performance or functionality.  An allegedly
faster way to find the cpu number is not a clear win (if the
percpu variable is in cache, then it is clearly faster to read
from memory).

2) Use ar.kr3 for cpu number, and then make the MCA code index an
array to get the phys address of the per-cpu area.
Messes with a lot of MCA code, and for a microscopic improvement
over my proposed getcpu() code.  Yes, you can avoid ever doing the system
call ... but only running the system call when you have migrated to a
different cpu should cover most calls [possible exception ... a future
scheduler might frequently move a process between logical cpus that
share all cache levels, since there is no cache penalty for running
on other cpus in the same cache domain].  So I'm not looking favourably
at this option at the moment ... but could change my mind if presented
with some data on getcpu() usage.

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Fri Feb 09 05:07:51 2007

This archive was generated by hypermail 2.1.8 : 2007-02-09 05:08:13 EST