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

From: Keith Owens <kaos_at_sgi.com>
Date: 2007-02-08 17:37:54
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Feb 08 17:38:30 2007

This archive was generated by hypermail 2.1.8 : 2007-02-08 17:39:04 EST