Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
Hi Artern, At 03/14/2018 05:07 PM, Artem Bityutskiy wrote: On Wed, 2018-03-14 at 12:11 +0800, Dou Liyang wrote: At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy Longer term, yeah, I agree. Kernel's notion of possible CPU count should be realistic. I did a patch for that, Artem, could you help me to test it. I didn't consider the nr_cpu_ids before. please ignore the old patch and try the following RFC patch. Sure I can help with testing a patch, could we please: 1. Start a new thread for this 2. Include ACPI forum/folks OK, I will do that right now. Thanks, dou Thanks, Artem.
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
Hi Artem,
At 03/14/2018 11:29 AM, Dou Liyang wrote:
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy
wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
because there are other resources allocated according to
num_possible_cpus(),
such as percpu variables.
Short term the regression should be fixed. It is already v4.16-rc6, we
have little time left.
Right.
Longer term, yeah, I agree. Kernel's notion of possible CPU count
should be realistic.
I did a patch for that, Artem, could you help me to test it.
I didn't consider the nr_cpu_ids before. please ignore the old patch and
try the following RFC patch.
Thanks
dou
--->8-
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 449d86d39965..96d568408515 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -671,6 +671,23 @@ static acpi_status __init
acpi_processor_ids_walk(acpi_handle handle,
}
+static void __init acpi_refill_possible_map(void)
+{
+ unsigned int cpu, nr = 0;
+
+ if (nr_cpu_ids <= nr_unique_ids)
+ return;
+
+ for_each_possible_cpu(cpu) {
+ if (nr >= nr_unique_ids)
+ set_cpu_possible(cpu, false);
+ nr++;
+ }
+
+ nr_cpu_ids = nr_unique_ids;
+ pr_info("Allowing %d possible CPUs\n", nr_cpu_ids);
+}
+
static void __init acpi_processor_check_duplicates(void)
{
/* check the correctness for all processors in ACPI namespace */
@@ -680,6 +697,9 @@ static void __init acpi_processor_check_duplicates(void)
NULL, NULL, NULL);
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
acpi_processor_ids_walk,
NULL, NULL);
+
+ /* make possible CPU count more realistic */
+ acpi_refill_possible_map();
}
bool acpi_duplicate_processor_id(int proc_id)
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
Hi Rafael, Thank you so much for your reply. At 03/13/2018 05:25 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 4:11 AM, Dou Liyang wrote: Hi Thomas, At 03/09/2018 11:08 PM, Thomas Gleixner wrote: [...] I'm not sure if there is a clear indicator whether physcial hotplug is supported or not, but the ACPI folks (x86) and architecture maintainers +cc Rafael should be able to answer that question. I have a machine which says: smpboot: Allowing 128 CPUs, 96 hotplug CPUs There is definitely no way to hotplug anything on that machine and sure the AFAIK, in ACPI based dynamic reconfiguration, there is no clear indicator. In theory, If the ACPI tables have the hotpluggable CPU resources, the OS can support physical hotplug. In order for the ACPI-based CPU hotplug (I mean physical, not just the software offline/online we do in the kernel) to work, there have to be objects in the ACPI namespace corresponding to all of the processors in question. If they are not present, there is no way to signal insertion and eject the processors safely. Yes, I see. Thanks dou
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
Hi All,
At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote:
On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote:
On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote:
Then looks this issue need to fix by making possible CPU count
accurate
because there are other resources allocated according to
num_possible_cpus(),
such as percpu variables.
Short term the regression should be fixed. It is already v4.16-rc6, we
have little time left.
Right.
Longer term, yeah, I agree. Kernel's notion of possible CPU count
should be realistic.
I did a patch for that, Artem, could you help me to test it.
--->8-
diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 449d86d39965..878abfa0ce30 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -671,6 +671,18 @@ static acpi_status __init
acpi_processor_ids_walk(acpi_handle handle,
}
+static void __init acpi_refill_possible_map(void)
+{
+ int i;
+
+ reset_cpu_possible_mask();
+
+ for (i = 0; i < nr_unique_ids; i++)
+ set_cpu_possible(i, true);
+
+ pr_info("Allowing %d possible CPUs\n", nr_unique_ids);
+}
+
static void __init acpi_processor_check_duplicates(void)
{
/* check the correctness for all processors in ACPI namespace */
@@ -680,6 +692,9 @@ static void __init acpi_processor_check_duplicates(void)
NULL, NULL, NULL);
acpi_get_devices(ACPI_PROCESSOR_DEVICE_HID,
acpi_processor_ids_walk,
NULL, NULL);
+
+ /* make possible CPU count more realistic */
+ acpi_refill_possible_map();
}
bool acpi_duplicate_processor_id(int proc_id)
--
I agree.
Moreover, there are not too many systems where physical CPU hotplug
actually works in practice AFAICS, so IMO we should default to "no
physical CPU hotplug" and only change that default in special cases
(which may be hard to figure out, but that's a different matter).
Yes, I think so.
What platform firmware tells us may be completely off.
Rafeal,
Sorry, I am not sure what you mean :-) . Did you mean no platform
firmware can tell us whether physcial CPU hotplug is supported or not?
My colleagues also told to me that there is no way in OS to know whether
it is supported or not.
Thanks
dou
Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible
Hi Thomas, At 03/09/2018 11:08 PM, Thomas Gleixner wrote: [...] I'm not sure if there is a clear indicator whether physcial hotplug is supported or not, but the ACPI folks (x86) and architecture maintainers +cc Rafael should be able to answer that question. I have a machine which says: smpboot: Allowing 128 CPUs, 96 hotplug CPUs There is definitely no way to hotplug anything on that machine and sure the AFAIK, in ACPI based dynamic reconfiguration, there is no clear indicator. In theory, If the ACPI tables have the hotpluggable CPU resources, the OS can support physical hotplug. For your machine, Did your CPUs support multi-threading, but not enable it? And, sometimes we should not trust the number of possible CPUs. I also met the situation that BIOS told to ACPI that it could support physical CPUs hotplug, But actually, there was no hardware slots in the machine. the ACPI tables like user inputs which should be validated when we use. existing spread algorithm will waste vectors to no end. Sure then there is virt, which can pretend to have a gazillion of possible hotpluggable CPUs, but virt is an insanity on its own. Though someone might come up with reasonable heuristics for that as well. Thoughts? Do we have to map the vectors to CPU statically? Can we map them when we hotplug/enable the possible CPU? Thanks, dou
