From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933102AbbIYTop (ORCPT ); Fri, 25 Sep 2015 15:44:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45285 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932891AbbIYToo (ORCPT ); Fri, 25 Sep 2015 15:44:44 -0400 Message-ID: <5605A429.3080308@redhat.com> Date: Fri, 25 Sep 2015 21:44:41 +0200 From: Denys Vlasenko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jiang Liu , Ingo Molnar CC: Thomas Gleixner , Len Brown , X86 ML , LKML Subject: Re: x86_64: MAX_LOCAL_APIC way too big? References: <56057344.2070206@redhat.com> <56057CCC.4010409@linux.intel.com> In-Reply-To: <56057CCC.4010409@linux.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.