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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/