From: Denys Vlasenko <dvlasenk@redhat.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>,
Jiang Liu <jiang.liu@linux.intel.com>,
Len Brown <len.brown@intel.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS
Date: Wed, 30 Sep 2015 17:49:13 +0200 [thread overview]
Message-ID: <560C0479.2080602@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1509301709220.4500@nanos>
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?
My patch will work fine for this machine,
with any CONFIG_MAX_LAPIC_ID.
next prev parent reply other threads:[~2015-09-30 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 19:48 [PATCH RFC] x86: Reduce MAX_LOCAL_APIC and MAX_IO_APICS Denys Vlasenko
2015-09-30 15:11 ` Thomas Gleixner
2015-09-30 15:49 ` Denys Vlasenko [this message]
2015-09-30 17:03 ` Jiang Liu
2015-09-30 17:43 ` Thomas Gleixner
2015-09-30 17:18 ` Jiang Liu
-- strict thread matches above, loose matches on Subject: below --
2015-10-02 7:31 Daniel J Blueman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560C0479.2080602@redhat.com \
--to=dvlasenk@redhat.com \
--cc=jiang.liu@linux.intel.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.