From: Dou Liyang <douly.fnst@cn.fujitsu.com> To: mingo@kernel.org, tglx@linutronix.de, peterz@infradead.org, rjw@rjwysocki.net, hpa@zytor.com, rafael@kernel.org, cl@linux.com, tj@kernel.org, akpm@linux-foundation.org, rafael.j.wysocki@intel.com, len.brown@intel.com, izumi.taku@jp.fujitsu.com, xiaolong.ye@intel.com Cc: x86@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Dou Liyang <douly.fnst@cn.fujitsu.com> Subject: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Date: Mon, 20 Feb 2017 16:47:47 +0800 [thread overview] Message-ID: <1487580471-17665-1-git-send-email-douly.fnst@cn.fujitsu.com> (raw) Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time. It keeps consistent with the WorkQueue and avoids some bugs which may be caused by the dynamic assignment. As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2, 8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply speaking: Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT: We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT. So, we get the mapping of *Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT: The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in each entities. we just use it directly. So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to step1 and step2: *Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* But, The ACPI table is unreliable and it is very risky that we use the entity which isn't related to a physical device at booting time. Here has already two bugs we found. 1. Duplicated Processor IDs in DSDT. It has been fixed by commit 8e089eaa19, fd74da217d. 2. The _PXM in DSDT is inconsistent with the one in MADT. It may cause the bug, which is shown in: https://lkml.org/lkml/2017/2/12/200 There may be more later. We shouldn't just only fix them everytime, we should solve this problem from the source to avoid such problems happend again and again. Now, a simple and easy way is found, we revert our patches. Do the Step 2 at hot-plug time, not at booting time where we did some useless work. It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive use of the ACPI table. We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug. To Xiaolong: Please help me to test it in the special machine. Change log: v1 -> v2: 1. fix some comments. 2. add the verification of duplicate processor id. Dou Liyang (4): Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Revert"x86/acpi: Enable MADT APIs to return disabled apicids" acpi: Fix the check handle in case of declaring processors using the Device operator acpi: Move the verification of duplicate proc_id from booting time to hot-plug time arch/x86/kernel/acpi/boot.c | 2 +- drivers/acpi/acpi_processor.c | 50 +++++++++++----- drivers/acpi/bus.c | 1 - drivers/acpi/processor_core.c | 133 +++++++----------------------------------- include/linux/acpi.h | 5 +- 5 files changed, 59 insertions(+), 132 deletions(-) -- 2.5.5
WARNING: multiple messages have this Message-ID (diff)
From: Dou Liyang <douly.fnst@cn.fujitsu.com> To: <mingo@kernel.org>, <tglx@linutronix.de>, <peterz@infradead.org>, <rjw@rjwysocki.net>, <hpa@zytor.com>, <rafael@kernel.org>, <cl@linux.com>, <tj@kernel.org>, <akpm@linux-foundation.org>, <rafael.j.wysocki@intel.com>, <len.brown@intel.com>, <izumi.taku@jp.fujitsu.com>, <xiaolong.ye@intel.com> Cc: <x86@kernel.org>, <linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Dou Liyang <douly.fnst@cn.fujitsu.com> Subject: [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Date: Mon, 20 Feb 2017 16:47:47 +0800 [thread overview] Message-ID: <1487580471-17665-1-git-send-email-douly.fnst@cn.fujitsu.com> (raw) Currently, We make the mapping of "cpuid <-> nodeid" fixed at the booting time. It keeps consistent with the WorkQueue and avoids some bugs which may be caused by the dynamic assignment. As we know, It is implemented by the patches as follows: 2532fc318d, f7c28833c2, 8f54969dc8, 8ad893faf2, dc6db24d24, which depend on ACPI table. Simply speaking: Step 1. Make the "Logical CPU ID <-> Processor ID/UID" fixed Using MADT: We generate the logical CPU IDs by the Local APIC/x2APIC IDs orderly and get the mapping of Processor ID/UID <-> Local Apic ID directly in MADT. So, we get the mapping of *Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* Step 2. Make the "Processor ID/UID <-> Node ID(_PXM)" fixed Using DSDT: The maaping of "Processor ID/UID <-> Node ID(_PXM)" is ready-made in each entities. we just use it directly. So, at last we get the maaping of *Node ID <-> Logical CPU ID* according to step1 and step2: *Node ID(_PXM) <-> Processor ID/UID <-> Local Apic ID <-> Logical CPU ID* But, The ACPI table is unreliable and it is very risky that we use the entity which isn't related to a physical device at booting time. Here has already two bugs we found. 1. Duplicated Processor IDs in DSDT. It has been fixed by commit 8e089eaa19, fd74da217d. 2. The _PXM in DSDT is inconsistent with the one in MADT. It may cause the bug, which is shown in: https://lkml.org/lkml/2017/2/12/200 There may be more later. We shouldn't just only fix them everytime, we should solve this problem from the source to avoid such problems happend again and again. Now, a simple and easy way is found, we revert our patches. Do the Step 2 at hot-plug time, not at booting time where we did some useless work. It also can make the mapping of "cpuid <-> nodeid" fixed and avoid excessive use of the ACPI table. We have tested them in our box: Fujitsu PQ2000 with 2 nodes for hot-plug. To Xiaolong: Please help me to test it in the special machine. Change log: v1 -> v2: 1. fix some comments. 2. add the verification of duplicate processor id. Dou Liyang (4): Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Revert"x86/acpi: Enable MADT APIs to return disabled apicids" acpi: Fix the check handle in case of declaring processors using the Device operator acpi: Move the verification of duplicate proc_id from booting time to hot-plug time arch/x86/kernel/acpi/boot.c | 2 +- drivers/acpi/acpi_processor.c | 50 +++++++++++----- drivers/acpi/bus.c | 1 - drivers/acpi/processor_core.c | 133 +++++++----------------------------------- include/linux/acpi.h | 5 +- 5 files changed, 59 insertions(+), 132 deletions(-) -- 2.5.5
next reply other threads:[~2017-02-20 8:47 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-20 8:47 Dou Liyang [this message] 2017-02-20 8:47 ` [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Dou Liyang 2017-02-20 8:47 ` [PATCH v2 1/4] Revert"x86/acpi: Set persistent cpuid <-> nodeid mapping when booting" Dou Liyang 2017-02-20 8:47 ` Dou Liyang 2017-03-01 10:51 ` Thomas Gleixner 2017-03-02 7:58 ` Dou Liyang 2017-03-02 7:58 ` Dou Liyang 2017-02-20 8:47 ` [PATCH v2 2/4] Revert"x86/acpi: Enable MADT APIs to return disabled apicids" Dou Liyang 2017-02-20 8:47 ` Dou Liyang 2017-03-01 10:52 ` Thomas Gleixner 2017-03-02 8:02 ` Dou Liyang 2017-03-02 8:02 ` Dou Liyang 2017-02-20 8:47 ` [PATCH v2 3/4] acpi: Fix the check handle in case of declaring processors using the Device operator Dou Liyang 2017-02-20 8:47 ` Dou Liyang 2017-03-01 11:12 ` Thomas Gleixner 2017-03-02 8:12 ` Dou Liyang 2017-03-02 8:12 ` Dou Liyang 2017-02-20 8:47 ` [PATCH v2 4/4] acpi: Move the verification of duplicate proc_id from booting time to hot-plug time Dou Liyang 2017-02-20 8:47 ` Dou Liyang 2017-03-01 11:26 ` Thomas Gleixner 2017-03-02 8:20 ` Dou Liyang 2017-03-02 8:20 ` Dou Liyang 2017-02-21 1:02 ` [PATCH v2 0/4] Revert works for the mapping of cpuid <-> nodeid Ye Xiaolong 2017-02-21 7:10 ` Ye Xiaolong 2017-02-21 7:10 ` Ye Xiaolong 2017-02-22 1:56 ` Dou Liyang 2017-02-22 1:56 ` Dou Liyang 2017-02-22 1:56 ` Dou Liyang 2017-03-16 8:14 ` [LKP] " Aaron Lu 2017-03-16 8:14 ` Aaron Lu 2017-03-16 8:28 ` [LKP] " Thomas Gleixner 2017-03-16 8:28 ` Thomas Gleixner 2017-03-16 8:38 ` [LKP] " Aaron Lu 2017-03-16 8:38 ` Aaron Lu
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=1487580471-17665-1-git-send-email-douly.fnst@cn.fujitsu.com \ --to=douly.fnst@cn.fujitsu.com \ --cc=akpm@linux-foundation.org \ --cc=cl@linux.com \ --cc=hpa@zytor.com \ --cc=izumi.taku@jp.fujitsu.com \ --cc=len.brown@intel.com \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=rafael.j.wysocki@intel.com \ --cc=rafael@kernel.org \ --cc=rjw@rjwysocki.net \ --cc=tglx@linutronix.de \ --cc=tj@kernel.org \ --cc=x86@kernel.org \ --cc=xiaolong.ye@intel.com \ /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: linkBe 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.