Messages in this thread | | | Date | Fri, 25 Sep 2015 21:44:41 +0200 | From | Denys Vlasenko <> | Subject | Re: x86_64: MAX_LOCAL_APIC way too big? |
| |
On 09/25/2015 06:56 PM, Jiang Liu wrote: > On 2015/9/26 0:16, Denys Vlasenko wrote: >> 32 thousand APICs? That's a lot. Especially >> considering that event with CONFIG_MAXSMP=y, >> NR_CPUS is "only" 8096. >> >> After a quick glance through code, it looks like >> such a big value causes several data arrays to be >> quite oversized: >> >> phys_cpu_present_map is 4 kbytes (one bit per apicid) >> __apicid_to_node is 64 kbytes >> apic_version is 128 kbytes (!!!) >> ... >> Maybe we can reduce MAX_LOCAL_APIC? >> Why it has to be this big in the first place? >> >> IIRC: APIC id at first was just a 8-bit quantity, >> then x2apic mode it was extended to 32 bits. >> >> On "usual" systems, apic ids simply go from zero >> to maximum logical CPU number, mirroring CPU ids.
> Hi Denys, > The above assumption is risky with modern > x86 platforms. APIC ids are assigned by firmware, > and may be discrete.
I guess it means a new CONFIG option will be needed then, for such machines. I'll send an RFC patch now.
| |