From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932317AbbI3RDt (ORCPT ); Wed, 30 Sep 2015 13:03:49 -0400 Received: from mga11.intel.com ([192.55.52.93]:54442 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753080AbbI3RDr (ORCPT ); Wed, 30 Sep 2015 13:03:47 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,613,1437462000"; d="scan'208";a="816479980" Subject: Re: [PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS To: Denys Vlasenko , Thomas Gleixner References: <1443210512-24236-1-git-send-email-dvlasenk@redhat.com> <560C0479.2080602@redhat.com> Cc: Ingo Molnar , Len Brown , x86@kernel.org, linux-kernel@vger.kernel.org From: Jiang Liu Organization: Intel Message-ID: <560C15EB.1000200@linux.intel.com> Date: Thu, 1 Oct 2015 01:03:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <560C0479.2080602@redhat.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 2015/9/30 23:49, Denys Vlasenko wrote: > On 09/30/2015 05:11 PM, Thomas Gleixner wrote: >> On Fri, 25 Sep 2015, Denys Vlasenko wrote: >>> >>> +config MAX_LAPIC_ID >>> + int "Maximum APIC ID" >>> + range 8 32768 >>> + default "8" >>> + ---help--- >>> + Use this option to set maximum allowed Local APIC ID higher than >>> + maximum number of CPUs. This may be necessary for machines >>> + with large number of processor sockets and non-contiguous >>> + LAPIC numbering. >>> + This setting will be automatically rounded up, if necessary. >> >> This is wrong. If you would limit the APIC IDs then you really break >> stuff. You can only limit the number of APICs. > > This CONFIG setting allows to _increase_ max APIC ID. > > Check out this part of the patch: > > +/* > + * Allow non-contiguous APIC IDs for small machines: > + * APIC ids 0..15 are valid in any config. > + * Typical SMP machines have contiguous APIC IDs: 0..NR_CPUS-1. > + * CONFIG_MAX_LAPIC_ID can override. > + */ > +#define MAX_LOCAL_APIC (NR_CPUS < 16 ? 16 : NR_CPUS) > +#if MAX_LOCAL_APIC < CONFIG_MAX_LAPIC_ID > +# undef MAX_LOCAL_APIC > +# define MAX_LOCAL_APIC CONFIG_MAX_LAPIC_ID > #endif > > > For example, if you'd build with NR_CPUS=128 > (for example, Fedora kernels do that), > max accepted APIC id will be NR_CPUS-1 = 127 > even if CONFIX_MAX_LAPIC_ID is 8. > > If Fedora would want to support APIC ids up to > 255, it will need to set CONFIG_MAX_LAPIC_ID=256. > > Otherwise, if it's happy with "only" supporting up to 128, > it does not need to change CONFIG_MAX_LAPIC_ID from default. > > With current kernels, max APIC id for any kernel is 32768, > which is in most cases way bigger than necessary. > > > Perhaps I need to update the text. > Something like: > > - This setting will be automatically rounded up, if necessary > + This setting will be increased to NR_CPUS, if necessary > > >> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) >> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) > > Does it mean that on a 2-CPU machine, CPU #1 has APIC_ID=2? Yes, APIC IDs are assigned by BIOS and may not be continuous.