lkml.org 
[lkml]   [2015]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.




\
 
 \ /
  Last update: 2015-10-03 22:41    [W:0.107 / U:0.212 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site