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

From: Keith Owens <>
Date: 2007-02-08 17:55:04
Keith Owens (on Thu, 08 Feb 2007 17:37:54 +1100) wrote:
>Zou Nan hai (on 08 Feb 2007 12:27:31 +0800) wrote:
>>On Thu, 2007-02-08 at 14:04, Keith Owens wrote:
>>> Zou Nan hai (on 08 Feb 2007 11:28:44 +0800) wrote:
>>> >Pin ar.kr2 of each CPU, so that smp_processor_id can use it.
>>> Historically ar.k2 has been reserved for debugging purposes, for
>>> example in ivt.S.  Debuggers often need a location that can be used to
>>> track progress, it has to be somewhere that does not rely on TLB
>>> entries and is guaranteed to appear in MCA/INIT records - ar.k2 is
>>> perfect for this.
>>  Ok, seems that current kr3 is only used by ia64_itc_printk_clock?
>>> Use Tony's suggestion of testing for a change in ar.k3 (guaranteed to
>>> be unique on every cpu) and caching the corresponding cpu number when
>>> it changes.
>>  But why do we even need to cache it? 
>>  It is already in a register if we put it to kr3. 
>>  so smp_processor_id() could be very fast. and later sys_getcpu can
>>also be very fast.
>ar.k3 is currently used for the address of the per-cpu data area, which
>speeds up access to all the per-cpu data.  Changing ar.k3 to hold the
>cpu number means an extra array calculation and lookup for every
>per-cpu variable, slowing down the rest of the system.

Correction: ar.k3 contains the physical address of the per-cpu data
area, virtual access to per-cpu data goes via the cpu local TLB and
does not rely on an ar.k<n> variable.  ar.k3 is used in the MCA
assembler handler, see GET_THIS_PADDR in include/asm-ia64/mca_asm.h and

To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Thu Feb 08 17:55:20 2007

This archive was generated by hypermail 2.1.8 : 2007-02-08 17:56:06 EST