lkml.org 
[lkml]   [2003]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: APIC version
Date
From
I don't think the array apic_version[] is very helpful in the first place.
I suspect it can be __init.

Jun

> -----Original Message-----
> From: Protasevich, Natalie [mailto:Natalie.Protasevich@UNISYS.com]
> Sent: Monday, January 13, 2003 3:15 PM
> To: 'Zwane Mwaikambo'; Nakajima, Jun
> Cc: Protasevich, Natalie; Martin J. Bligh; Pallipadi, Venkatesh; William
> Lee Irwin III; Christoph Hellwig; James Cleverdon; Linux Kernel
> Subject: RE: APIC version
>
> As for apic_version[] indexing in general, I am also for smp_processor_id,
> although it could take a few changes in apic.c, mpparse.c, and especially
> smpboot.c. Speaking of es7000, its APIC ID's are always huge, defined by
> fixed topology. For those like us, the array would shrink from MAX_APICS
> (256) to NR_CPUS (32, maybe 64). I wonder if it would do any good for
> (true)
> NUMA.
>
> --Natalie
>
> -----Original Message-----
> From: Zwane Mwaikambo [mailto:zwane@holomorphy.com]
> Sent: Monday, January 13, 2003 3:53 PM
> To: Nakajima, Jun
> Cc: Protasevich, Natalie; Martin J. Bligh; Pallipadi, Venkatesh; William
> Lee Irwin III; Christoph Hellwig; James Cleverdon; Linux Kernel
> Subject: RE: APIC version
>
>
> On Mon, 13 Jan 2003, Nakajima, Jun wrote:
>
> > 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?
>
> Zwane
> --
> function.linuxpower.ca
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.551 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site