RE: APIC version

[Nakajima, Jun]

We can gather that info at runtime from the processors, when we really need it. And I don't think we have performance issues this that.

Jun

> -----Original Message-----
> From: Protasevich, Natalie [mailto:[e-mail]]
> Sent: Monday, January 13, 2003 3:49 PM
> To: 'Martin J. Bligh'; Zwane Mwaikambo; Nakajima, Jun
> Cc: Protasevich, Natalie; Pallipadi, Venkatesh; William Lee Irwin III;
> Christoph Hellwig; James Cleverdon; Linux Kernel
> Subject: RE: APIC version
> 
> If you index it by 4-bit GET_APIC_ID() (not GET_APIC_LOGICAL_ID()), i.e.
> hard_smp_processor_id(), you can get away with it.
> 
> Of course, it is possible that it can just be "don't care":
> 
> >I don't think the array apic_version[] is very helpful in the first
> place.
> >I suspect it can be __init.
> 
> >Jun
> 
> On the other hand, it might be needed if imagine hot plug CPU case.
> 
> 
> --Natalie
> 
> 
> 
> -----Original Message-----
> From: Martin J. Bligh [mailto:[e-mail]]
> Sent: Monday, January 13, 2003 4:23 PM
> To: Zwane Mwaikambo; Nakajima, Jun
> Cc: Protasevich, Natalie; Pallipadi, Venkatesh; William Lee Irwin III;
> Christoph Hellwig; James Cleverdon; Linux Kernel
> Subject: RE: APIC version
> 
> 
> >> The entries in acpi_version[] are indexed by the APIC id, not
> >> smp_processor_id(). So you can overwrite acpi_version[] for a different
> >> processor.
> >
> > Is it possible to use smp_processor_id instead to avoid wasting memory
> > for the sparse APIC id case?
> 
> No, the array is set up in mpparse.c before we know the real processor
> numbers.
> 
> M.