Messages in this thread | | | Date | Sat, 03 Oct 2015 22:26:32 +0200 | From | Denys Vlasenko <> | Subject | Re: [PATCH 3/3] x86/apic: Use smaller array for __apicid_to_node[] mapping |
| |
On 10/03/2015 09:44 AM, Ingo Molnar wrote: > > * Denys Vlasenko <dvlasenk@redhat.com> wrote: > >> @@ -56,16 +56,34 @@ early_param("numa", numa_setup); >> /* >> * apicid, cpu, node mappings >> */ >> -s16 __apicid_to_node[MAX_LOCAL_APICID] = { >> - [0 ... MAX_LOCAL_APICID-1] = NUMA_NO_NODE >> + >> +struct apicid_to_node __apicid_to_node[NR_CPUS] = { >> + [0 ... NR_CPUS-1] = {-1, NUMA_NO_NODE} >> }; >> >> +void set_apicid_to_node(int apicid, s16 node) >> +{ >> + static int ent; > > having such statics inside functions is really obscure and makes review harder. > I had to look twice to see it. Please move it outside and also name it > appropriately.
Just to confirm: you want it to be a static data, but not inside a function?
>> + /* Protect against small kernel on large system */ >> + if (ent >= NR_CPUS) >> + return; >> + >> + __apicid_to_node[ent].apicid = apicid; >> + __apicid_to_node[ent].node = node; >> + ent++; >> +} > > So what happens if we run a small kernel and run out of entries? We just silently > seem to return, no warning, no nothing - the system will likely fail to boot in > myserious ways, right?
Good question.
I tested this.
I built a NR_CPUS=8 kernel and booted it on 144 cpu and 240 cpu machines. Both booted fine:
[ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached. Processor 8/0x16 ignored. ... [ 0.000000] ACPI: NR_CPUS/possible_cpus limit of 8 reached. Processor 143/0xf7 ignored.
| |