Hi,
On 05/19/2016 10:46 PM, Peter Zijlstra wrote:
On Thu, May 19, 2016 at 06:39:41PM +0800, Zhu Guihua wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doin
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/ia64/kernel/acpi.c | 3 +-
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/x
correctly, they are assigned the same value.
The wrong value will be used by our patch, and lead to panic.
Thanks,
Zhu
On 05/19/2016 06:39 PM, Zhu Guihua wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_c
hen cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will chan
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
Hi Lorenzo,
Thanks for your test and detailed suggestions.
I will update those later.
Thanks,
Zhu
On 04/06/2016 10:29 PM, Lorenzo Pieralisi wrote:
[+Dennis since he reported ARM64 build breakage]
On Thu, Mar 17, 2016 at 09:32:40AM +0800, Zhu Guihua wrote:
From: Gu Zheng
The whole patch
Hi Rafael,
On 04/06/2016 11:21 PM, Rafael J. Wysocki wrote:
On 4/6/2016 2:43 AM, kernel test robot wrote:
FYI, we noticed the below changes on
https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
linux-next
commit f962c29c2f5d80be28bd76e2c3fadf1ce97ccd76 ("x86, ACPI,
cpu-hotpl
hen cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will chan
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/x
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/ia64/kernel/acpi.c | 2 +-
/commits/Zhu-Guihua/Make-cpuid-nodeid-mapping-persistent/20160303-094713
config: ia64-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save
Hi,
On 03/03/2016 10:08 AM, Rafael J. Wysocki wrote:
Hi,
On Thu, Mar 3, 2016 at 2:42 AM, Zhu Guihua wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doin
Hi Thomas, Ingo, hpa,
Would you please help to review the X86 part of this patch-set ?
Thanks,
Zhu
On 03/03/2016 09:42 AM, Zhu Guihua wrote:
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_num
hen cpus
on these memory-less nodes try to allocate memory from local node, it
will automatically fall back to the proper zones in the zonelists.
Signed-off-by: Zhu Guihua
---
arch/x86/mm/numa.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/arch/x86/
[Problem]
cpuid <-> nodeid mapping is firstly established at boot time. And workqueue
caches
the mapping in wq_numa_possible_cpumask in wq_numa_init() at boot time.
When doing node online/offline, cpuid <-> nodeid mapping is
established/destroyed,
which means, cpuid <-> nodeid mapping will chan
27;
apicid.
This is also done by introducing an extra parameter to these apis to let the
caller
control if disabled cpus are ignored.
4. Establish all possible cpuid <-> nodeid mapping.
This is done via an additional acpi namespace walk for processors.
This patch finished step 1.
control if disabled processors are ignored.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
drivers/acpi/acpi_processor.c | 5 +++-
drivers/acpi/processor_core.c | 57 +++
2 files changed, 40 insertions(+), 22 deletions(-)
<-> apicid mapping is established at local apic registeration time.
But non-present or disabled cpus are ignored.
In this patch, we establish all possible cpuid <-> apicid mapping when
registering local apic.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/x
s step 4.
This patch set the persistent cpuid <-> nodeid mapping for all enabled/disabled
processors at boot time via an additional acpi namespace walk for processors.
Signed-off-by: Gu Zheng
Signed-off-by: Tang Chen
Signed-off-by: Zhu Guihua
---
arch/ia64/kernel/acpi.c | 2 +-
Hi Rafael,
On 02/03/2016 08:02 PM, Rafael J. Wysocki wrote:
Hi,
On Wed, Feb 3, 2016 at 10:14 AM, Zhu Guihua wrote:
On 01/25/2016 02:12 PM, Tang Chen wrote:
Hi Rafael, Len,
Would you please help to review the ACPI part of this patch-set ?
Can anyone help to review this?
I'm planni
On 01/25/2016 02:12 PM, Tang Chen wrote:
Hi Rafael, Len,
Would you please help to review the ACPI part of this patch-set ?
Can anyone help to review this?
Cc tj:
Can you add acked-by into this patchset?
Thanks.
Thanks.
On 01/25/2016 02:08 PM, Tang Chen wrote:
[Problem]
cpuid <-> nodeid
On 12/21/2015 03:17 PM, Joonsoo Kim wrote:
On Mon, Dec 21, 2015 at 03:00:08PM +0800, Zhu Guihua wrote:
On 12/21/2015 11:15 AM, Joonsoo Kim wrote:
Hello, memory-hotplug folks.
I found theoretical problems between memory hotplug and pfn iterator.
For example, pfn iterator works something like
On 12/21/2015 11:15 AM, Joonsoo Kim wrote:
Hello, memory-hotplug folks.
I found theoretical problems between memory hotplug and pfn iterator.
For example, pfn iterator works something like below.
for (pfn = zone_start_pfn; pfn < zone_end_pfn; pfn++) {
if (!pfn_valid(pfn))
Commit-ID: 20d5e4a9cd453991e2590a4c25230a99b42dee0c
Gitweb: http://git.kernel.org/tip/20d5e4a9cd453991e2590a4c25230a99b42dee0c
Author: Zhu Guihua
AuthorDate: Fri, 3 Jul 2015 17:37:19 +0800
Committer: Ingo Molnar
CommitDate: Mon, 6 Jul 2015 15:00:34 +0200
x86/espfix: Init espfix on the
Commit-ID: 1db875631f8d5bbf497f67e47f254eece888d51d
Gitweb: http://git.kernel.org/tip/1db875631f8d5bbf497f67e47f254eece888d51d
Author: Zhu Guihua
AuthorDate: Fri, 3 Jul 2015 17:37:18 +0800
Committer: Ingo Molnar
CommitDate: Mon, 6 Jul 2015 15:00:33 +0200
x86/espfix: Add
CPU is bringing up by the
primary CPU
-commit messages changed
v1:
-Alloc the page on the node the target CPU is on.
Zhu Guihua (2):
espfix: add cpu parameter to init_espfix_ap()
x86, espfix: init espfix on the boot cpu side
arch/x86/include/asm/espfix.h | 2 +-
arch/x86/kernel
Add cpu index parameter to init_espfix_ap(), so that the parameter
could be propagated to the function for pages allocation.
Signed-off-by: Zhu Guihua
---
arch/x86/include/asm/espfix.h | 2 +-
arch/x86/kernel/espfix_64.c | 7 +++
arch/x86/kernel/smpboot.c | 2 +-
3 files changed, 5
alloc_pages_node() with the secondary CPU's node, to make sure
the espfix stack is NUMA-local to the CPU that is going to use it.
Signed-off-by: Zhu Guihua
---
arch/x86/kernel/espfix_64.c | 21 +
arch/x86/kernel/smpboot.c | 14 +++---
2 files changed, 20 inser
local irq disabled,
then trigger the warning as mentioned about.
So we allocate them on the boot CPU side when the target CPU is bringing
up by the primary CPU, and hand them over to the secondary CPU.
Signed-off-by: Zhu Guihua
---
v2:
-allocate espfix stack pages when the targert CPU is bringing
Any feedback about this?
On 06/04/2015 05:45 PM, Gu Zheng wrote:
The following lockdep warning occurrs when running with latest kernel:
[3.178000] [ cut here ]
[3.183000] WARNING: CPU: 128 PID: 0 at kernel/locking/lockdep.c:2755
lockdep_trace_alloc+0xdd/0xe0()
[
On 06/10/2015 04:29 AM, Andrew Morton wrote:
On Tue, 9 Jun 2015 11:41:28 +0800 Zhu Guihua wrote:
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -513,6 +513,7 @@ int __ref __add_pages(int nid, struct zone *zone, unsigned
long phys_start_pfn,
break
On 06/09/2015 07:30 AM, Andrew Morton wrote:
On Mon, 8 Jun 2015 14:44:41 +0800 Zhu Guihua wrote:
When hot add two nodes continuously, we found the vmemmap region info is a
bit messed. The last region of node 2 is printed when node 3 hot added,
like the following:
Initmem setup node 2 [mem
egion at the end of hot add
memory to avoid the confusion.
Signed-off-by: Zhu Guihua
---
mm/memory_hotplug.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 457bde5..58fb223 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -513,6 +513
39 matches
Mail list logo
