* [PATCH v3 00/12] ACPI NUMA support for ARM64
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Based on Ganapat's v9 dt based NUMA patch set [1] for ARM64, this
patch set introduce the ACPI based configuration to provide
NUMA information.
ACPI 5.1 already introduced NUMA support for ARM64, which can
get the NUMA domain information from SRAT and SLIT table, so
parse those two tables to get mappings from cpu/mem to numa
node configration and system locality.
v3 updates:
- Deep investigation about the ACPI_DEBUG_PRINT() and remvoe
that for acpi/numa.c (patch 2/12)
- Remove the duplicate NULL check for table print (patch 3/12)
- Introduce CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP to remove duplicate
dummy function for acpi_numa_arch_fixup()
- Solve the problem that the mapping from logical cpu to numa node
is wrong which spotted out by Lorenzo
- cleanups for x86 and move acpi_numa_slit_init() and some other
functions to common place, then reduce the duplicate of x86
and arm64 (patch 7-12/12).
- rebased on top of 4.4 and Ganapat's v9 patch set.
This patch set was tested By Ganapat on Cavium Thunder-X, it works
fine.
[1]: http://lwn.net/Articles/672329/
Thanks
Hanjun
Hanjun Guo (12):
acpi, numa: Use pr_fmt() instead of printk
acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
acpi, numa: remove duplicate NULL check
acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
arm64, acpi, numa: NUMA support based on SRAT and SLIT
acpi, numa: Enable ACPI based NUMA on ARM64
acpi, numa: move acpi_numa_slit_init() to common place
arm64, numa: rework numa_add_memblk()
x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
acpi, numa: move bad_srat() and srat_disabled() to common place
acpi, numa: remove unneeded acpi_numa=1
acpi, numa: reuse acpi_numa_memory_affinity_init()
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 149 +++++++++++++++++++++++++++++++
arch/arm64/kernel/of_numa.c | 2 +-
arch/arm64/kernel/smp.c | 3 +
arch/arm64/mm/numa.c | 17 ++--
arch/ia64/Kconfig | 1 +
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 113 +----------------------
drivers/acpi/Kconfig | 5 +-
drivers/acpi/numa.c | 202 +++++++++++++++++++++++++++++++-----------
include/acpi/acpi_numa.h | 12 +++
include/linux/acpi.h | 22 ++++-
15 files changed, 365 insertions(+), 176 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
--
1.9.1
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 00/12] ACPI NUMA support for ARM64
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Based on Ganapat's v9 dt based NUMA patch set [1] for ARM64, this
patch set introduce the ACPI based configuration to provide
NUMA information.
ACPI 5.1 already introduced NUMA support for ARM64, which can
get the NUMA domain information from SRAT and SLIT table, so
parse those two tables to get mappings from cpu/mem to numa
node configration and system locality.
v3 updates:
- Deep investigation about the ACPI_DEBUG_PRINT() and remvoe
that for acpi/numa.c (patch 2/12)
- Remove the duplicate NULL check for table print (patch 3/12)
- Introduce CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP to remove duplicate
dummy function for acpi_numa_arch_fixup()
- Solve the problem that the mapping from logical cpu to numa node
is wrong which spotted out by Lorenzo
- cleanups for x86 and move acpi_numa_slit_init() and some other
functions to common place, then reduce the duplicate of x86
and arm64 (patch 7-12/12).
- rebased on top of 4.4 and Ganapat's v9 patch set.
This patch set was tested By Ganapat on Cavium Thunder-X, it works
fine.
[1]: http://lwn.net/Articles/672329/
Thanks
Hanjun
Hanjun Guo (12):
acpi, numa: Use pr_fmt() instead of printk
acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
acpi, numa: remove duplicate NULL check
acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
arm64, acpi, numa: NUMA support based on SRAT and SLIT
acpi, numa: Enable ACPI based NUMA on ARM64
acpi, numa: move acpi_numa_slit_init() to common place
arm64, numa: rework numa_add_memblk()
x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
acpi, numa: move bad_srat() and srat_disabled() to common place
acpi, numa: remove unneeded acpi_numa=1
acpi, numa: reuse acpi_numa_memory_affinity_init()
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 149 +++++++++++++++++++++++++++++++
arch/arm64/kernel/of_numa.c | 2 +-
arch/arm64/kernel/smp.c | 3 +
arch/arm64/mm/numa.c | 17 ++--
arch/ia64/Kconfig | 1 +
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 113 +----------------------
drivers/acpi/Kconfig | 5 +-
drivers/acpi/numa.c | 202 +++++++++++++++++++++++++++++++-----------
include/acpi/acpi_numa.h | 12 +++
include/linux/acpi.h | 22 ++++-
15 files changed, 365 insertions(+), 176 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
--
1.9.1
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 01/12] acpi, numa: Use pr_fmt() instead of printk
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Just do some cleanups to replace printk with pr_fmt().
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 72b6e9e..4e427fc 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -18,6 +18,9 @@
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
*/
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -28,8 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define PREFIX "ACPI: "
-
#define ACPI_NUMA 0x80000000
#define _COMPONENT ACPI_NUMA
ACPI_MODULE_NAME("numa");
@@ -187,9 +188,8 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
#endif /* ACPI_DEBUG_OUTPUT */
break;
default:
- printk(KERN_WARNING PREFIX
- "Found unsupported SRAT entry (type = 0x%x)\n",
- header->type);
+ pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
+ header->type);
break;
}
}
@@ -222,7 +222,7 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
if (!slit_valid(slit)) {
- printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
+ pr_info("SLIT table looks invalid. Not used.\n");
return -EINVAL;
}
acpi_numa_slit_init(slit);
@@ -233,12 +233,9 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
void __init __weak
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
{
- printk(KERN_WARNING PREFIX
- "Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
- return;
+ pr_warn("Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
}
-
static int __init
acpi_parse_x2apic_affinity(struct acpi_subtable_header *header,
const unsigned long end)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 01/12] acpi, numa: Use pr_fmt() instead of printk
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Just do some cleanups to replace printk with pr_fmt().
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 72b6e9e..4e427fc 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -18,6 +18,9 @@
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
*/
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -28,8 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define PREFIX "ACPI: "
-
#define ACPI_NUMA 0x80000000
#define _COMPONENT ACPI_NUMA
ACPI_MODULE_NAME("numa");
@@ -187,9 +188,8 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
#endif /* ACPI_DEBUG_OUTPUT */
break;
default:
- printk(KERN_WARNING PREFIX
- "Found unsupported SRAT entry (type = 0x%x)\n",
- header->type);
+ pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
+ header->type);
break;
}
}
@@ -222,7 +222,7 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
if (!slit_valid(slit)) {
- printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
+ pr_info("SLIT table looks invalid. Not used.\n");
return -EINVAL;
}
acpi_numa_slit_init(slit);
@@ -233,12 +233,9 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
void __init __weak
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
{
- printk(KERN_WARNING PREFIX
- "Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
- return;
+ pr_warn("Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
}
-
static int __init
acpi_parse_x2apic_affinity(struct acpi_subtable_header *header,
const unsigned long end)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 01/12] acpi, numa: Use pr_fmt() instead of printk
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Just do some cleanups to replace printk with pr_fmt().
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 17 +++++++----------
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 72b6e9e..4e427fc 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -18,6 +18,9 @@
* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*
*/
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
@@ -28,8 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define PREFIX "ACPI: "
-
#define ACPI_NUMA 0x80000000
#define _COMPONENT ACPI_NUMA
ACPI_MODULE_NAME("numa");
@@ -187,9 +188,8 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
#endif /* ACPI_DEBUG_OUTPUT */
break;
default:
- printk(KERN_WARNING PREFIX
- "Found unsupported SRAT entry (type = 0x%x)\n",
- header->type);
+ pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
+ header->type);
break;
}
}
@@ -222,7 +222,7 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
if (!slit_valid(slit)) {
- printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n");
+ pr_info("SLIT table looks invalid. Not used.\n");
return -EINVAL;
}
acpi_numa_slit_init(slit);
@@ -233,12 +233,9 @@ static int __init acpi_parse_slit(struct acpi_table_header *table)
void __init __weak
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
{
- printk(KERN_WARNING PREFIX
- "Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
- return;
+ pr_warn("Found unsupported x2apic [0x%08x] SRAT entry\n", pa->apic_id);
}
-
static int __init
acpi_parse_x2apic_affinity(struct acpi_subtable_header *header,
const unsigned long end)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 02/12] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
ACPI_DEBUG_PRINT is a bit fragile in acpi/numa.c, the first thing
is that component ACPI_NUMA(0x80000000) is not described in the
Documentation/acpi/debug.txt, and even not defined in the struct
acpi_dlayer acpi_debug_layers which we can not dynamically enable/disable
it with /sys/modules/acpi/parameters/debug_layer. another thing
is that ACPI_DEBUG_OUTPUT is controlled by ACPICA which not coordinate
well with ACPI drivers.
Replace ACPI_DEBUG_PRINT() with pr_debug() in this patch as pr_debug
will do the same thing for debug purpose and it can make the code much
cleaner, also remove the related code which not needed anymore if
ACPI_DEBUG_PRINT() is gone.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 59 +++++++++++++++++++----------------------------------
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4e427fc..e34b5d0 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -31,10 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define ACPI_NUMA 0x80000000
-#define _COMPONENT ACPI_NUMA
-ACPI_MODULE_NAME("numa");
-
static nodemask_t nodes_found_map = NODE_MASK_NONE;
/* maps to convert between proximity domain and logical node ID */
@@ -129,64 +125,51 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
-
- ACPI_FUNCTION_NAME("acpi_table_print_srat_entry");
-
if (!header)
return;
switch (header->type) {
-
case ACPI_SRAT_TYPE_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_cpu_affinity *p =
(struct acpi_srat_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
- p->apic_id, p->local_sapic_eid,
- p->proximity_domain_lo,
- (p->flags & ACPI_SRAT_CPU_ENABLED)?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
+ p->apic_id, p->local_sapic_eid,
+ p->proximity_domain_lo,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_mem_affinity *p =
(struct acpi_srat_mem_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
- (unsigned long)p->base_address,
- (unsigned long)p->length,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_MEM_ENABLED)?
- "enabled" : "disabled",
- (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)?
- " hot-pluggable" : "",
- (p->flags & ACPI_SRAT_MEM_NON_VOLATILE)?
- " non-volatile" : ""));
+ pr_debug("SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
+ (unsigned long)p->base_address,
+ (unsigned long)p->length,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_MEM_ENABLED) ?
+ "enabled" : "disabled",
+ (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) ?
+ " hot-pluggable" : "",
+ (p->flags & ACPI_SRAT_MEM_NON_VOLATILE) ?
+ " non-volatile" : "");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_x2apic_cpu_affinity *p =
(struct acpi_srat_x2apic_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (x2apicid[0x%08x]) in"
- " proximity domain %d %s\n",
- p->apic_id,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_CPU_ENABLED) ?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (x2apicid[0x%08x]) in proximity domain %d %s\n",
+ p->apic_id,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 02/12] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
ACPI_DEBUG_PRINT is a bit fragile in acpi/numa.c, the first thing
is that component ACPI_NUMA(0x80000000) is not described in the
Documentation/acpi/debug.txt, and even not defined in the struct
acpi_dlayer acpi_debug_layers which we can not dynamically enable/disable
it with /sys/modules/acpi/parameters/debug_layer. another thing
is that ACPI_DEBUG_OUTPUT is controlled by ACPICA which not coordinate
well with ACPI drivers.
Replace ACPI_DEBUG_PRINT() with pr_debug() in this patch as pr_debug
will do the same thing for debug purpose and it can make the code much
cleaner, also remove the related code which not needed anymore if
ACPI_DEBUG_PRINT() is gone.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 59 +++++++++++++++++++----------------------------------
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4e427fc..e34b5d0 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -31,10 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define ACPI_NUMA 0x80000000
-#define _COMPONENT ACPI_NUMA
-ACPI_MODULE_NAME("numa");
-
static nodemask_t nodes_found_map = NODE_MASK_NONE;
/* maps to convert between proximity domain and logical node ID */
@@ -129,64 +125,51 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
-
- ACPI_FUNCTION_NAME("acpi_table_print_srat_entry");
-
if (!header)
return;
switch (header->type) {
-
case ACPI_SRAT_TYPE_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_cpu_affinity *p =
(struct acpi_srat_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
- p->apic_id, p->local_sapic_eid,
- p->proximity_domain_lo,
- (p->flags & ACPI_SRAT_CPU_ENABLED)?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
+ p->apic_id, p->local_sapic_eid,
+ p->proximity_domain_lo,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_mem_affinity *p =
(struct acpi_srat_mem_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
- (unsigned long)p->base_address,
- (unsigned long)p->length,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_MEM_ENABLED)?
- "enabled" : "disabled",
- (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)?
- " hot-pluggable" : "",
- (p->flags & ACPI_SRAT_MEM_NON_VOLATILE)?
- " non-volatile" : ""));
+ pr_debug("SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
+ (unsigned long)p->base_address,
+ (unsigned long)p->length,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_MEM_ENABLED) ?
+ "enabled" : "disabled",
+ (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) ?
+ " hot-pluggable" : "",
+ (p->flags & ACPI_SRAT_MEM_NON_VOLATILE) ?
+ " non-volatile" : "");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_x2apic_cpu_affinity *p =
(struct acpi_srat_x2apic_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (x2apicid[0x%08x]) in"
- " proximity domain %d %s\n",
- p->apic_id,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_CPU_ENABLED) ?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (x2apicid[0x%08x]) in proximity domain %d %s\n",
+ p->apic_id,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 02/12] acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
ACPI_DEBUG_PRINT is a bit fragile in acpi/numa.c, the first thing
is that component ACPI_NUMA(0x80000000) is not described in the
Documentation/acpi/debug.txt, and even not defined in the struct
acpi_dlayer acpi_debug_layers which we can not dynamically enable/disable
it with /sys/modules/acpi/parameters/debug_layer. another thing
is that ACPI_DEBUG_OUTPUT is controlled by ACPICA which not coordinate
well with ACPI drivers.
Replace ACPI_DEBUG_PRINT() with pr_debug() in this patch as pr_debug
will do the same thing for debug purpose and it can make the code much
cleaner, also remove the related code which not needed anymore if
ACPI_DEBUG_PRINT() is gone.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 59 +++++++++++++++++++----------------------------------
1 file changed, 21 insertions(+), 38 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4e427fc..e34b5d0 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -31,10 +31,6 @@
#include <linux/nodemask.h>
#include <linux/topology.h>
-#define ACPI_NUMA 0x80000000
-#define _COMPONENT ACPI_NUMA
-ACPI_MODULE_NAME("numa");
-
static nodemask_t nodes_found_map = NODE_MASK_NONE;
/* maps to convert between proximity domain and logical node ID */
@@ -129,64 +125,51 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
-
- ACPI_FUNCTION_NAME("acpi_table_print_srat_entry");
-
if (!header)
return;
switch (header->type) {
-
case ACPI_SRAT_TYPE_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_cpu_affinity *p =
(struct acpi_srat_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
- p->apic_id, p->local_sapic_eid,
- p->proximity_domain_lo,
- (p->flags & ACPI_SRAT_CPU_ENABLED)?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (id[0x%02x] eid[0x%02x]) in proximity domain %d %s\n",
+ p->apic_id, p->local_sapic_eid,
+ p->proximity_domain_lo,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_MEMORY_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_mem_affinity *p =
(struct acpi_srat_mem_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
- (unsigned long)p->base_address,
- (unsigned long)p->length,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_MEM_ENABLED)?
- "enabled" : "disabled",
- (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE)?
- " hot-pluggable" : "",
- (p->flags & ACPI_SRAT_MEM_NON_VOLATILE)?
- " non-volatile" : ""));
+ pr_debug("SRAT Memory (0x%lx length 0x%lx) in proximity domain %d %s%s%s\n",
+ (unsigned long)p->base_address,
+ (unsigned long)p->length,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_MEM_ENABLED) ?
+ "enabled" : "disabled",
+ (p->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) ?
+ " hot-pluggable" : "",
+ (p->flags & ACPI_SRAT_MEM_NON_VOLATILE) ?
+ " non-volatile" : "");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
case ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY:
-#ifdef ACPI_DEBUG_OUTPUT
{
struct acpi_srat_x2apic_cpu_affinity *p =
(struct acpi_srat_x2apic_cpu_affinity *)header;
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
- "SRAT Processor (x2apicid[0x%08x]) in"
- " proximity domain %d %s\n",
- p->apic_id,
- p->proximity_domain,
- (p->flags & ACPI_SRAT_CPU_ENABLED) ?
- "enabled" : "disabled"));
+ pr_debug("SRAT Processor (x2apicid[0x%08x]) in proximity domain %d %s\n",
+ p->apic_id,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_CPU_ENABLED) ?
+ "enabled" : "disabled");
}
-#endif /* ACPI_DEBUG_OUTPUT */
break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 03/12] acpi, numa: remove duplicate NULL check
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
The argument "header" for acpi_table_print_srat_entry()
is always checked before the function is called, it's
duplicate to check it again, remove it.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index e34b5d0..2de6068 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -125,9 +125,6 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
- if (!header)
- return;
-
switch (header->type) {
case ACPI_SRAT_TYPE_CPU_AFFINITY:
{
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 03/12] acpi, numa: remove duplicate NULL check
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
The argument "header" for acpi_table_print_srat_entry()
is always checked before the function is called, it's
duplicate to check it again, remove it.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index e34b5d0..2de6068 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -125,9 +125,6 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
- if (!header)
- return;
-
switch (header->type) {
case ACPI_SRAT_TYPE_CPU_AFFINITY:
{
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 03/12] acpi, numa: remove duplicate NULL check
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
The argument "header" for acpi_table_print_srat_entry()
is always checked before the function is called, it's
duplicate to check it again, remove it.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/numa.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index e34b5d0..2de6068 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -125,9 +125,6 @@ EXPORT_SYMBOL(acpi_map_pxm_to_online_node);
static void __init
acpi_table_print_srat_entry(struct acpi_subtable_header *header)
{
- if (!header)
- return;
-
switch (header->type) {
case ACPI_SRAT_TYPE_CPU_AFFINITY:
{
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, linux-kernel,
Robert Richter, linux-acpi, Shannon Zhao, Ganapatrao Kulkarni,
linux-arm-kernel, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
function for it, when we came to a new architecture (such as ARM64),
we need to introduce another dummy one to make the code compile.
That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
then it's pretty clean for x86 and ARM64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/Kconfig | 1 +
arch/x86/mm/srat.c | 2 --
drivers/acpi/Kconfig | 3 +++
include/linux/acpi.h | 5 +++++
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e..1285cef 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -17,6 +17,7 @@ config IA64
select ACPI if (!IA64_HP_SIM)
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
+ select ACPI_HAS_NUMA_ARCH_FIXUP if ACPI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index c2aea63..9fa1746 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -210,8 +210,6 @@ out_err:
return -1;
}
-void __init acpi_numa_arch_fixup(void) {}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5eef4cb..d6d5749 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
config ACPI_CCA_REQUIRED
bool
+config ACPI_HAS_NUMA_ARCH_FIXUP
+ bool
+
config ACPI_DEBUGGER
bool "AML debugger interface (EXPERIMENTAL)"
select ACPI_DEBUG
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1991aea..574d829 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -173,7 +173,12 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
+
+#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
void acpi_numa_arch_fixup(void);
+#else
+static inline void acpi_numa_arch_fixup(void) { }
+#endif
#ifndef PHYS_CPUID_INVALID
typedef u32 phys_cpuid_t;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
function for it, when we came to a new architecture (such as ARM64),
we need to introduce another dummy one to make the code compile.
That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
then it's pretty clean for x86 and ARM64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/Kconfig | 1 +
arch/x86/mm/srat.c | 2 --
drivers/acpi/Kconfig | 3 +++
include/linux/acpi.h | 5 +++++
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e..1285cef 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -17,6 +17,7 @@ config IA64
select ACPI if (!IA64_HP_SIM)
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
+ select ACPI_HAS_NUMA_ARCH_FIXUP if ACPI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index c2aea63..9fa1746 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -210,8 +210,6 @@ out_err:
return -1;
}
-void __init acpi_numa_arch_fixup(void) {}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5eef4cb..d6d5749 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
config ACPI_CCA_REQUIRED
bool
+config ACPI_HAS_NUMA_ARCH_FIXUP
+ bool
+
config ACPI_DEBUGGER
bool "AML debugger interface (EXPERIMENTAL)"
select ACPI_DEBUG
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1991aea..574d829 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -173,7 +173,12 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
+
+#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
void acpi_numa_arch_fixup(void);
+#else
+static inline void acpi_numa_arch_fixup(void) { }
+#endif
#ifndef PHYS_CPUID_INVALID
typedef u32 phys_cpuid_t;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
function for it, when we came to a new architecture (such as ARM64),
we need to introduce another dummy one to make the code compile.
That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
then it's pretty clean for x86 and ARM64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/ia64/Kconfig | 1 +
arch/x86/mm/srat.c | 2 --
drivers/acpi/Kconfig | 3 +++
include/linux/acpi.h | 5 +++++
4 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index eb0249e..1285cef 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -17,6 +17,7 @@ config IA64
select ACPI if (!IA64_HP_SIM)
select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
+ select ACPI_HAS_NUMA_ARCH_FIXUP if ACPI
select HAVE_UNSTABLE_SCHED_CLOCK
select HAVE_IDE
select HAVE_OPROFILE
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index c2aea63..9fa1746 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -210,8 +210,6 @@ out_err:
return -1;
}
-void __init acpi_numa_arch_fixup(void) {}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 5eef4cb..d6d5749 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -57,6 +57,9 @@ config ACPI_SYSTEM_POWER_STATES_SUPPORT
config ACPI_CCA_REQUIRED
bool
+config ACPI_HAS_NUMA_ARCH_FIXUP
+ bool
+
config ACPI_DEBUGGER
bool "AML debugger interface (EXPERIMENTAL)"
select ACPI_DEBUG
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 1991aea..574d829 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -173,7 +173,12 @@ void acpi_numa_slit_init (struct acpi_table_slit *slit);
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
+
+#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
void acpi_numa_arch_fixup(void);
+#else
+static inline void acpi_numa_arch_fixup(void) { }
+#endif
#ifndef PHYS_CPUID_INVALID
typedef u32 phys_cpuid_t;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 10:25 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-23 10:25 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:19, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
> function for it, when we came to a new architecture (such as ARM64),
> we need to introduce another dummy one to make the code compile.
>
> That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
> select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
> then it's pretty clean for x86 and ARM64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/ia64/Kconfig | 1 +
I see an implementation of acpi_numa_arch_fixup() only for ia64. Why
not move it to arch/ia64 then and call it from setup_arch() in
arch/ia64/kernel/setup.c after acpi_numa_init()? It looks like we
don't need a generic solution for this. This avoids any kconfig
handling for this at all.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
@ 2016-01-23 10:25 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-23 10:25 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:19, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
> function for it, when we came to a new architecture (such as ARM64),
> we need to introduce another dummy one to make the code compile.
>
> That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
> select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
> then it's pretty clean for x86 and ARM64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/ia64/Kconfig | 1 +
I see an implementation of acpi_numa_arch_fixup() only for ia64. Why
not move it to arch/ia64 then and call it from setup_arch() in
arch/ia64/kernel/setup.c after acpi_numa_init()? It looks like we
don't need a generic solution for this. This avoids any kconfig
handling for this at all.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
@ 2016-01-23 10:25 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-23 10:25 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:19, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
> function for it, when we came to a new architecture (such as ARM64),
> we need to introduce another dummy one to make the code compile.
>
> That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
> select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
> then it's pretty clean for x86 and ARM64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/ia64/Kconfig | 1 +
I see an implementation of acpi_numa_arch_fixup() only for ia64. Why
not move it to arch/ia64 then and call it from setup_arch() in
arch/ia64/kernel/setup.c after acpi_numa_init()? It looks like we
don't need a generic solution for this. This avoids any kconfig
handling for this at all.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
2016-01-23 10:25 ` Robert Richter
@ 2016-01-24 4:56 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-24 4:56 UTC (permalink / raw)
To: Robert Richter, Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland
On 01/23/2016 06:25 PM, Robert Richter wrote:
> On 23.01.16 17:39:19, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
>> function for it, when we came to a new architecture (such as ARM64),
>> we need to introduce another dummy one to make the code compile.
>>
>> That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
>> select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
>> then it's pretty clean for x86 and ARM64.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/ia64/Kconfig | 1 +
>
> I see an implementation of acpi_numa_arch_fixup() only for ia64. Why
> not move it to arch/ia64 then and call it from setup_arch() in
> arch/ia64/kernel/setup.c after acpi_numa_init()? It looks like we
> don't need a generic solution for this. This avoids any kconfig
> handling for this at all.
It's much simpler as you suggested, I will update it in next
version, thank you Robert :)
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 04/12] acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
@ 2016-01-24 4:56 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-24 4:56 UTC (permalink / raw)
To: linux-arm-kernel
On 01/23/2016 06:25 PM, Robert Richter wrote:
> On 23.01.16 17:39:19, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> acpi_numa_arch_fixup() is only used for IA64, x86 introduce a dummy
>> function for it, when we came to a new architecture (such as ARM64),
>> we need to introduce another dummy one to make the code compile.
>>
>> That's pretty boring so introduce ACPI_HAS_NUMA_ARCH_FIXUP and
>> select it for IA64, introduce a stub function for acpi_numa_arch_fixup()
>> then it's pretty clean for x86 and ARM64.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/ia64/Kconfig | 1 +
>
> I see an implementation of acpi_numa_arch_fixup() only for ia64. Why
> not move it to arch/ia64 then and call it from setup_arch() in
> arch/ia64/kernel/setup.c after acpi_numa_init()? It looks like we
> don't need a generic solution for this. This avoids any kconfig
> handling for this at all.
It's much simpler as you suggested, I will update it in next
version, thank you Robert :)
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Introduce a new file to hold ACPI based NUMA information
parsing from SRAT and SLIT.
SRAT includes the CPU ACPI ID to Proximity Domain mappings
and memory ranges to Proximity Domain mapping.
SLIT has the information of inter node
distances(relative number for access latency).
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 3 +
arch/arm64/mm/numa.c | 5 +-
6 files changed, 252 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..6db9c6f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
#endif
+#ifdef CONFIG_ACPI_NUMA
+int arm64_acpi_numa_init(void);
+void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
+#else
+static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
+static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
+#endif /* CONFIG_ACPI_NUMA */
+
#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 54deb38..1beb194 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -6,6 +6,8 @@
#ifdef CONFIG_NUMA
+#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
+
/* currently, arm64 implements flat NUMA topology */
#define parent_node(node) (node)
@@ -43,6 +45,7 @@ struct device_node;
int __init arm64_of_numa_init(void);
void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
#else
+static inline int arm64_of_numa_init(void) { return -ENODEV; }
static inline void of_numa_set_node_info(unsigned int cpu,
struct device_node *dn) { }
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7987763..555c4a5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
arm64-obj-$(CONFIG_ACPI) += acpi.o
arm64-obj-$(CONFIG_OF_NUMA) += of_numa.o
+arm64-obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
new file mode 100644
index 0000000..f7f7533
--- /dev/null
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -0,0 +1,235 @@
+/*
+ * ACPI 5.1 based NUMA setup for ARM64
+ * Lots of code was borrowed from arch/x86/mm/srat.c
+ *
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ * Copyright (C) 2013-2016, Linaro Ltd.
+ * Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#define pr_fmt(fmt) "ACPI: NUMA: " fmt
+
+#include <linux/acpi.h>
+#include <linux/bitmap.h>
+#include <linux/bootmem.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/memblock.h>
+#include <linux/mmzone.h>
+#include <linux/module.h>
+#include <linux/topology.h>
+
+#include <acpi/processor.h>
+#include <asm/numa.h>
+
+int acpi_numa __initdata;
+static int cpus_in_srat;
+
+struct __node_cpu_hwid {
+ u32 node_id; /* logical node containing this CPU */
+ u64 cpu_hwid; /* MPIDR for this CPU */
+};
+
+static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
+[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
+
+static __init void bad_srat(void)
+{
+ pr_err("SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
+
+void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
+{
+ int nid = 0, i;
+
+ for (i = 0; i < cpus_in_srat; i++) {
+ if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
+ nid = early_node_cpu_hwid[i].node_id;
+ break;
+ }
+ }
+
+ cpu_to_node_map[cpu] = nid;
+}
+
+/*
+ * Callback for SLIT parsing.
+ * It will get the distance information presented by SLIT
+ * and init the distance matrix of numa nodes
+ */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[
+ slit->locality_count * i + j]);
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
+static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
+{
+ unsigned long madt_end, entry;
+ struct acpi_table_madt *madt;
+ acpi_size tbl_size;
+
+ if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
+ (struct acpi_table_header **)&madt, &tbl_size)))
+ return -ENODEV;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ struct acpi_subtable_header *header =
+ (struct acpi_subtable_header *)entry;
+
+ if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+ struct acpi_madt_generic_interrupt *gicc =
+ container_of(header,
+ struct acpi_madt_generic_interrupt, header);
+
+ if ((gicc->flags & ACPI_MADT_ENABLED) &&
+ (gicc->uid == acpi_id)) {
+ *mpidr = gicc->arm_mpidr;
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return 0;
+ }
+ }
+ entry += header->length;
+ }
+
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return -ENODEV;
+}
+
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
+{
+ int pxm, node;
+ u64 mpidr;
+
+ if (srat_disabled())
+ return;
+
+ if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ bad_srat();
+ return;
+ }
+
+ if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+ return;
+
+ if (cpus_in_srat >= NR_CPUS) {
+ pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
+ NR_CPUS);
+ return;
+ }
+
+ pxm = pa->proximity_domain;
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains %d\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
+ pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pxm, pa->acpi_processor_uid);
+ bad_srat();
+ return;
+ }
+
+ early_node_cpu_hwid[cpus_in_srat].node_id = node;
+ early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ cpus_in_srat++;
+ pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+ pxm, mpidr, node, cpus_in_srat);
+}
+
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ int node, pxm;
+
+ if (srat_disabled())
+ return -EINVAL;
+
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ /* Ignore disabled entries */
+ if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
+ return -EINVAL;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains.\n");
+ bad_srat();
+ return -EINVAL;
+ }
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
+ if (numa_add_memblk(node, start, (end - start)) < 0) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init arm64_acpi_numa_init(void)
+{
+ int ret;
+
+ ret = acpi_numa_init();
+ if (ret)
+ return ret;
+
+ return srat_disabled() ? -EINVAL : 0;
+}
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a2a8c2d..112a892 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
/* map the logical cpu id to cpu MPIDR */
cpu_logical_map(cpu_count) = hwid;
+ /* map logical cpu to node */
+ acpi_numa_set_node_info(cpu_count, hwid);
+
cpu_count++;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9e8704b..e974995 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/ctype.h>
#include <linux/init.h>
@@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
{
int ret = -ENODEV;
-#ifdef CONFIG_OF_NUMA
if (!numa_off)
- ret = numa_init(arm64_of_numa_init);
-#endif
+ ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
if (ret)
numa_init(dummy_numa_init);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Introduce a new file to hold ACPI based NUMA information
parsing from SRAT and SLIT.
SRAT includes the CPU ACPI ID to Proximity Domain mappings
and memory ranges to Proximity Domain mapping.
SLIT has the information of inter node
distances(relative number for access latency).
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 3 +
arch/arm64/mm/numa.c | 5 +-
6 files changed, 252 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..6db9c6f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
#endif
+#ifdef CONFIG_ACPI_NUMA
+int arm64_acpi_numa_init(void);
+void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
+#else
+static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
+static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
+#endif /* CONFIG_ACPI_NUMA */
+
#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 54deb38..1beb194 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -6,6 +6,8 @@
#ifdef CONFIG_NUMA
+#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
+
/* currently, arm64 implements flat NUMA topology */
#define parent_node(node) (node)
@@ -43,6 +45,7 @@ struct device_node;
int __init arm64_of_numa_init(void);
void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
#else
+static inline int arm64_of_numa_init(void) { return -ENODEV; }
static inline void of_numa_set_node_info(unsigned int cpu,
struct device_node *dn) { }
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7987763..555c4a5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
arm64-obj-$(CONFIG_ACPI) += acpi.o
arm64-obj-$(CONFIG_OF_NUMA) += of_numa.o
+arm64-obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
new file mode 100644
index 0000000..f7f7533
--- /dev/null
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -0,0 +1,235 @@
+/*
+ * ACPI 5.1 based NUMA setup for ARM64
+ * Lots of code was borrowed from arch/x86/mm/srat.c
+ *
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ * Copyright (C) 2013-2016, Linaro Ltd.
+ * Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#define pr_fmt(fmt) "ACPI: NUMA: " fmt
+
+#include <linux/acpi.h>
+#include <linux/bitmap.h>
+#include <linux/bootmem.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/memblock.h>
+#include <linux/mmzone.h>
+#include <linux/module.h>
+#include <linux/topology.h>
+
+#include <acpi/processor.h>
+#include <asm/numa.h>
+
+int acpi_numa __initdata;
+static int cpus_in_srat;
+
+struct __node_cpu_hwid {
+ u32 node_id; /* logical node containing this CPU */
+ u64 cpu_hwid; /* MPIDR for this CPU */
+};
+
+static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
+[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
+
+static __init void bad_srat(void)
+{
+ pr_err("SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
+
+void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
+{
+ int nid = 0, i;
+
+ for (i = 0; i < cpus_in_srat; i++) {
+ if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
+ nid = early_node_cpu_hwid[i].node_id;
+ break;
+ }
+ }
+
+ cpu_to_node_map[cpu] = nid;
+}
+
+/*
+ * Callback for SLIT parsing.
+ * It will get the distance information presented by SLIT
+ * and init the distance matrix of numa nodes
+ */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[
+ slit->locality_count * i + j]);
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
+static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
+{
+ unsigned long madt_end, entry;
+ struct acpi_table_madt *madt;
+ acpi_size tbl_size;
+
+ if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
+ (struct acpi_table_header **)&madt, &tbl_size)))
+ return -ENODEV;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ struct acpi_subtable_header *header =
+ (struct acpi_subtable_header *)entry;
+
+ if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+ struct acpi_madt_generic_interrupt *gicc =
+ container_of(header,
+ struct acpi_madt_generic_interrupt, header);
+
+ if ((gicc->flags & ACPI_MADT_ENABLED) &&
+ (gicc->uid == acpi_id)) {
+ *mpidr = gicc->arm_mpidr;
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return 0;
+ }
+ }
+ entry += header->length;
+ }
+
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return -ENODEV;
+}
+
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
+{
+ int pxm, node;
+ u64 mpidr;
+
+ if (srat_disabled())
+ return;
+
+ if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ bad_srat();
+ return;
+ }
+
+ if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+ return;
+
+ if (cpus_in_srat >= NR_CPUS) {
+ pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
+ NR_CPUS);
+ return;
+ }
+
+ pxm = pa->proximity_domain;
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains %d\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
+ pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pxm, pa->acpi_processor_uid);
+ bad_srat();
+ return;
+ }
+
+ early_node_cpu_hwid[cpus_in_srat].node_id = node;
+ early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ cpus_in_srat++;
+ pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+ pxm, mpidr, node, cpus_in_srat);
+}
+
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ int node, pxm;
+
+ if (srat_disabled())
+ return -EINVAL;
+
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ /* Ignore disabled entries */
+ if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
+ return -EINVAL;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains.\n");
+ bad_srat();
+ return -EINVAL;
+ }
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
+ if (numa_add_memblk(node, start, (end - start)) < 0) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init arm64_acpi_numa_init(void)
+{
+ int ret;
+
+ ret = acpi_numa_init();
+ if (ret)
+ return ret;
+
+ return srat_disabled() ? -EINVAL : 0;
+}
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a2a8c2d..112a892 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
/* map the logical cpu id to cpu MPIDR */
cpu_logical_map(cpu_count) = hwid;
+ /* map logical cpu to node */
+ acpi_numa_set_node_info(cpu_count, hwid);
+
cpu_count++;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9e8704b..e974995 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/ctype.h>
#include <linux/init.h>
@@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
{
int ret = -ENODEV;
-#ifdef CONFIG_OF_NUMA
if (!numa_off)
- ret = numa_init(arm64_of_numa_init);
-#endif
+ ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
if (ret)
numa_init(dummy_numa_init);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Introduce a new file to hold ACPI based NUMA information
parsing from SRAT and SLIT.
SRAT includes the CPU ACPI ID to Proximity Domain mappings
and memory ranges to Proximity Domain mapping.
SLIT has the information of inter node
distances(relative number for access latency).
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
---
arch/arm64/include/asm/acpi.h | 8 ++
arch/arm64/include/asm/numa.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/smp.c | 3 +
arch/arm64/mm/numa.c | 5 +-
6 files changed, 252 insertions(+), 3 deletions(-)
create mode 100644 arch/arm64/kernel/acpi_numa.c
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index caafd63..6db9c6f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
#endif
+#ifdef CONFIG_ACPI_NUMA
+int arm64_acpi_numa_init(void);
+void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
+#else
+static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
+static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
+#endif /* CONFIG_ACPI_NUMA */
+
#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 54deb38..1beb194 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -6,6 +6,8 @@
#ifdef CONFIG_NUMA
+#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
+
/* currently, arm64 implements flat NUMA topology */
#define parent_node(node) (node)
@@ -43,6 +45,7 @@ struct device_node;
int __init arm64_of_numa_init(void);
void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
#else
+static inline int arm64_of_numa_init(void) { return -ENODEV; }
static inline void of_numa_set_node_info(unsigned int cpu,
struct device_node *dn) { }
#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7987763..555c4a5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
arm64-obj-$(CONFIG_ACPI) += acpi.o
arm64-obj-$(CONFIG_OF_NUMA) += of_numa.o
+arm64-obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
new file mode 100644
index 0000000..f7f7533
--- /dev/null
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -0,0 +1,235 @@
+/*
+ * ACPI 5.1 based NUMA setup for ARM64
+ * Lots of code was borrowed from arch/x86/mm/srat.c
+ *
+ * Copyright 2004 Andi Kleen, SuSE Labs.
+ * Copyright (C) 2013-2016, Linaro Ltd.
+ * Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
+ *
+ * Called from acpi_numa_init while reading the SRAT and SLIT tables.
+ * Assumes all memory regions belonging to a single proximity domain
+ * are in one chunk. Holes between them will be included in the node.
+ */
+
+#define pr_fmt(fmt) "ACPI: NUMA: " fmt
+
+#include <linux/acpi.h>
+#include <linux/bitmap.h>
+#include <linux/bootmem.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/memblock.h>
+#include <linux/mmzone.h>
+#include <linux/module.h>
+#include <linux/topology.h>
+
+#include <acpi/processor.h>
+#include <asm/numa.h>
+
+int acpi_numa __initdata;
+static int cpus_in_srat;
+
+struct __node_cpu_hwid {
+ u32 node_id; /* logical node containing this CPU */
+ u64 cpu_hwid; /* MPIDR for this CPU */
+};
+
+static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
+[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
+
+static __init void bad_srat(void)
+{
+ pr_err("SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static __init inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
+
+void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
+{
+ int nid = 0, i;
+
+ for (i = 0; i < cpus_in_srat; i++) {
+ if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
+ nid = early_node_cpu_hwid[i].node_id;
+ break;
+ }
+ }
+
+ cpu_to_node_map[cpu] = nid;
+}
+
+/*
+ * Callback for SLIT parsing.
+ * It will get the distance information presented by SLIT
+ * and init the distance matrix of numa nodes
+ */
+void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[
+ slit->locality_count * i + j]);
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
+static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
+{
+ unsigned long madt_end, entry;
+ struct acpi_table_madt *madt;
+ acpi_size tbl_size;
+
+ if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
+ (struct acpi_table_header **)&madt, &tbl_size)))
+ return -ENODEV;
+
+ entry = (unsigned long)madt;
+ madt_end = entry + madt->header.length;
+
+ /* Parse all entries looking for a match. */
+ entry += sizeof(struct acpi_table_madt);
+ while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
+ struct acpi_subtable_header *header =
+ (struct acpi_subtable_header *)entry;
+
+ if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+ struct acpi_madt_generic_interrupt *gicc =
+ container_of(header,
+ struct acpi_madt_generic_interrupt, header);
+
+ if ((gicc->flags & ACPI_MADT_ENABLED) &&
+ (gicc->uid == acpi_id)) {
+ *mpidr = gicc->arm_mpidr;
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return 0;
+ }
+ }
+ entry += header->length;
+ }
+
+ early_acpi_os_unmap_memory(madt, tbl_size);
+ return -ENODEV;
+}
+
+/* Callback for Proximity Domain -> ACPI processor UID mapping */
+void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
+{
+ int pxm, node;
+ u64 mpidr;
+
+ if (srat_disabled())
+ return;
+
+ if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ bad_srat();
+ return;
+ }
+
+ if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
+ return;
+
+ if (cpus_in_srat >= NR_CPUS) {
+ pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
+ NR_CPUS);
+ return;
+ }
+
+ pxm = pa->proximity_domain;
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains %d\n", pxm);
+ bad_srat();
+ return;
+ }
+
+ if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
+ pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pxm, pa->acpi_processor_uid);
+ bad_srat();
+ return;
+ }
+
+ early_node_cpu_hwid[cpus_in_srat].node_id = node;
+ early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
+ node_set(node, numa_nodes_parsed);
+ acpi_numa = 1;
+ cpus_in_srat++;
+ pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
+ pxm, mpidr, node, cpus_in_srat);
+}
+
+/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
+int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ int node, pxm;
+
+ if (srat_disabled())
+ return -EINVAL;
+
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ /* Ignore disabled entries */
+ if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
+ return -EINVAL;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+
+ node = acpi_map_pxm_to_node(pxm);
+
+ if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
+ pr_err("SRAT: Too many proximity domains.\n");
+ bad_srat();
+ return -EINVAL;
+ }
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
+ if (numa_add_memblk(node, start, (end - start)) < 0) {
+ bad_srat();
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int __init arm64_acpi_numa_init(void)
+{
+ int ret;
+
+ ret = acpi_numa_init();
+ if (ret)
+ return ret;
+
+ return srat_disabled() ? -EINVAL : 0;
+}
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index a2a8c2d..112a892 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
/* map the logical cpu id to cpu MPIDR */
cpu_logical_map(cpu_count) = hwid;
+ /* map logical cpu to node */
+ acpi_numa_set_node_info(cpu_count, hwid);
+
cpu_count++;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9e8704b..e974995 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/ctype.h>
#include <linux/init.h>
@@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
{
int ret = -ENODEV;
-#ifdef CONFIG_OF_NUMA
if (!numa_off)
- ret = numa_init(arm64_of_numa_init);
-#endif
+ ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
if (ret)
numa_init(dummy_numa_init);
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-25 10:21 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:21 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:20, Hanjun Guo wrote:
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c
> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> + u64 start, end;
> + int node, pxm;
> +
> + if (srat_disabled())
> + return -EINVAL;
> +
> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
Must be:
ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
Allow extensions to struct acpi_srat_mem_affinity in newer versions.
> + bad_srat();
> + return -EINVAL;
We need a pr_err() here to avoid that numa setup fails silently due to
bad fw. This applies to all error paths.
See my delta patch below. You can merge it with your patch.
-Robert
> + }
>From 78945c73e4ec03756a135a75133ed29694a7a0f2 Mon Sep 17 00:00:00 2001
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Nov 2015 09:53:39 +0100
Subject: [PATCH] arm64, acpi, numa: Add error messages for bad SRAT tables
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/kernel/acpi_numa.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533761cd..936ad6c43740 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -143,6 +143,8 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
return;
if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ pr_err("SRAT: Invalid SRAT header length: %d\n",
+ pa->header.length);
bad_srat();
return;
}
@@ -166,7 +168,7 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
}
if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
- pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
pxm, pa->acpi_processor_uid);
bad_srat();
return;
@@ -190,7 +192,9 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (srat_disabled())
return -EINVAL;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ if (ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
+ pr_err("SRAT: Unexpected header length: %d\n",
+ ma->header.length);
bad_srat();
return -EINVAL;
}
@@ -216,10 +220,17 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
(unsigned long long) start, (unsigned long long) end - 1);
if (numa_add_memblk(node, start, (end - start)) < 0) {
+ pr_err("SRAT: Failed to add memblk to node %u [mem %#010Lx-%#010Lx]\n",
+ node, (unsigned long long) start,
+ (unsigned long long) end - 1);
bad_srat();
return -EINVAL;
}
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
return 0;
}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-25 10:21 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:21 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:20, Hanjun Guo wrote:
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c
> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> + u64 start, end;
> + int node, pxm;
> +
> + if (srat_disabled())
> + return -EINVAL;
> +
> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
Must be:
ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
Allow extensions to struct acpi_srat_mem_affinity in newer versions.
> + bad_srat();
> + return -EINVAL;
We need a pr_err() here to avoid that numa setup fails silently due to
bad fw. This applies to all error paths.
See my delta patch below. You can merge it with your patch.
-Robert
> + }
>From 78945c73e4ec03756a135a75133ed29694a7a0f2 Mon Sep 17 00:00:00 2001
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Nov 2015 09:53:39 +0100
Subject: [PATCH] arm64, acpi, numa: Add error messages for bad SRAT tables
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/kernel/acpi_numa.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533761cd..936ad6c43740 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -143,6 +143,8 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
return;
if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ pr_err("SRAT: Invalid SRAT header length: %d\n",
+ pa->header.length);
bad_srat();
return;
}
@@ -166,7 +168,7 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
}
if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
- pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
pxm, pa->acpi_processor_uid);
bad_srat();
return;
@@ -190,7 +192,9 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (srat_disabled())
return -EINVAL;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ if (ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
+ pr_err("SRAT: Unexpected header length: %d\n",
+ ma->header.length);
bad_srat();
return -EINVAL;
}
@@ -216,10 +220,17 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
(unsigned long long) start, (unsigned long long) end - 1);
if (numa_add_memblk(node, start, (end - start)) < 0) {
+ pr_err("SRAT: Failed to add memblk to node %u [mem %#010Lx-%#010Lx]\n",
+ node, (unsigned long long) start,
+ (unsigned long long) end - 1);
bad_srat();
return -EINVAL;
}
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
return 0;
}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-25 10:21 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:21 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:20, Hanjun Guo wrote:
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c
> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> + u64 start, end;
> + int node, pxm;
> +
> + if (srat_disabled())
> + return -EINVAL;
> +
> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
Must be:
ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
Allow extensions to struct acpi_srat_mem_affinity in newer versions.
> + bad_srat();
> + return -EINVAL;
We need a pr_err() here to avoid that numa setup fails silently due to
bad fw. This applies to all error paths.
See my delta patch below. You can merge it with your patch.
-Robert
> + }
>From 78945c73e4ec03756a135a75133ed29694a7a0f2 Mon Sep 17 00:00:00 2001
From: Robert Richter <rrichter@cavium.com>
Date: Wed, 11 Nov 2015 09:53:39 +0100
Subject: [PATCH] arm64, acpi, numa: Add error messages for bad SRAT tables
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/kernel/acpi_numa.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533761cd..936ad6c43740 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -143,6 +143,8 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
return;
if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
+ pr_err("SRAT: Invalid SRAT header length: %d\n",
+ pa->header.length);
bad_srat();
return;
}
@@ -166,7 +168,7 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
}
if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
- pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
+ pr_err("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
pxm, pa->acpi_processor_uid);
bad_srat();
return;
@@ -190,7 +192,9 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (srat_disabled())
return -EINVAL;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
+ if (ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
+ pr_err("SRAT: Unexpected header length: %d\n",
+ ma->header.length);
bad_srat();
return -EINVAL;
}
@@ -216,10 +220,17 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
(unsigned long long) start, (unsigned long long) end - 1);
if (numa_add_memblk(node, start, (end - start)) < 0) {
+ pr_err("SRAT: Failed to add memblk to node %u [mem %#010Lx-%#010Lx]\n",
+ node, (unsigned long long) start,
+ (unsigned long long) end - 1);
bad_srat();
return -EINVAL;
}
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1);
+
return 0;
}
--
2.7.0.rc3
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-25 10:21 ` Robert Richter
(?)
@ 2016-01-27 7:12 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 7:12 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/25 18:21, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>> new file mode 100644
>> index 0000000..f7f7533
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi_numa.c
>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>> +{
>> + u64 start, end;
>> + int node, pxm;
>> +
>> + if (srat_disabled())
>> + return -EINVAL;
>> +
>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> Must be:
>
> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>
> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
Hmm, I think we need to remove the check here now.
There are three cases:
- firmware ACPI version is consistent with the ACPICA one, then
ma->header.length == sizeof(struct acpi_srat_mem_affinity )
- firmware ACPI version is not consistent with the ACPICA one,
for example, struct acpi_srat_mem_affinity is extended in
new ACI version, but the formware is using the older one,
then it's ok to use
ma->header.length < sizeof(struct acpi_srat_mem_affinity )
- but if we use the older kernel + updated new firmware,
then
ma->header.length > sizeof(struct acpi_srat_mem_affinity )
will be the case, right?
>
>> + bad_srat();
>> + return -EINVAL;
> We need a pr_err() here to avoid that numa setup fails silently due to
> bad fw. This applies to all error paths.
>
> See my delta patch below. You can merge it with your patch.
Thanks! I wil merge it into next version.
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-27 7:12 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 7:12 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/25 18:21, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>> new file mode 100644
>> index 0000000..f7f7533
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi_numa.c
>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>> +{
>> + u64 start, end;
>> + int node, pxm;
>> +
>> + if (srat_disabled())
>> + return -EINVAL;
>> +
>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> Must be:
>
> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>
> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
Hmm, I think we need to remove the check here now.
There are three cases:
- firmware ACPI version is consistent with the ACPICA one, then
ma->header.length == sizeof(struct acpi_srat_mem_affinity )
- firmware ACPI version is not consistent with the ACPICA one,
for example, struct acpi_srat_mem_affinity is extended in
new ACI version, but the formware is using the older one,
then it's ok to use
ma->header.length < sizeof(struct acpi_srat_mem_affinity )
- but if we use the older kernel + updated new firmware,
then
ma->header.length > sizeof(struct acpi_srat_mem_affinity )
will be the case, right?
>
>> + bad_srat();
>> + return -EINVAL;
> We need a pr_err() here to avoid that numa setup fails silently due to
> bad fw. This applies to all error paths.
>
> See my delta patch below. You can merge it with your patch.
Thanks! I wil merge it into next version.
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-27 7:12 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 7:12 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/25 18:21, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>> new file mode 100644
>> index 0000000..f7f7533
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi_numa.c
>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>> +{
>> + u64 start, end;
>> + int node, pxm;
>> +
>> + if (srat_disabled())
>> + return -EINVAL;
>> +
>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> Must be:
>
> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>
> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
Hmm, I think we need to remove the check here now.
There are three cases:
- firmware ACPI version is consistent with the ACPICA one, then
ma->header.length == sizeof(struct acpi_srat_mem_affinity )
- firmware ACPI version is not consistent with the ACPICA one,
for example, struct acpi_srat_mem_affinity is extended in
new ACI version, but the formware is using the older one,
then it's ok to use
ma->header.length < sizeof(struct acpi_srat_mem_affinity )
- but if we use the older kernel + updated new firmware,
then
ma->header.length > sizeof(struct acpi_srat_mem_affinity )
will be the case, right?
>
>> + bad_srat();
>> + return -EINVAL;
> We need a pr_err() here to avoid that numa setup fails silently due to
> bad fw. This applies to all error paths.
>
> See my delta patch below. You can merge it with your patch.
Thanks! I wil merge it into next version.
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-27 7:12 ` Hanjun Guo
(?)
@ 2016-01-27 14:01 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:01 UTC (permalink / raw)
To: Hanjun Guo
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, Rafael J. Wysocki,
Will Deacon, linux-kernel, linux-acpi, Shannon Zhao,
Catalin Marinas, Ganapatrao Kulkarni, linux-arm-kernel,
Hanjun Guo
On 27.01.16 15:12:15, Hanjun Guo wrote:
> On 2016/1/25 18:21, Robert Richter wrote:
> > On 23.01.16 17:39:20, Hanjun Guo wrote:
> >> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> >> new file mode 100644
> >> index 0000000..f7f7533
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/acpi_numa.c
> >> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> >> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> >> +{
> >> + u64 start, end;
> >> + int node, pxm;
> >> +
> >> + if (srat_disabled())
> >> + return -EINVAL;
> >> +
> >> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> > Must be:
> >
> > ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
> >
> > Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>
> Hmm, I think we need to remove the check here now.
No, we might have an out-of-bound access then.
>
> There are three cases:
>
> - firmware ACPI version is consistent with the ACPICA one, then
> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>
> - firmware ACPI version is not consistent with the ACPICA one,
> for example, struct acpi_srat_mem_affinity is extended in
> new ACI version, but the formware is using the older one,
> then it's ok to use
> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
The check above is ok as we need at least struct
acpi_srat_mem_affinity as it is now.
If we later change the kernel to support multiple versions of struct
acpi_srat_mem_affinity, i.e. use data from an extended section, we
will need to add code to handle that. This will include support of
data with length < acpi_srat_mem_affinity, in this case we may not use
extended data.
>
> - but if we use the older kernel + updated new firmware,
> then
> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
> will be the case, right?
Right, and this is a valid case not resulting in an error with my
suggestion above.
>
> >
> >> + bad_srat();
> >> + return -EINVAL;
> > We need a pr_err() here to avoid that numa setup fails silently due to
> > bad fw. This applies to all error paths.
> >
> > See my delta patch below. You can merge it with your patch.
>
> Thanks! I wil merge it into next version.
Thanks,
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-27 14:01 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:01 UTC (permalink / raw)
To: linux-arm-kernel
On 27.01.16 15:12:15, Hanjun Guo wrote:
> On 2016/1/25 18:21, Robert Richter wrote:
> > On 23.01.16 17:39:20, Hanjun Guo wrote:
> >> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> >> new file mode 100644
> >> index 0000000..f7f7533
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/acpi_numa.c
> >> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> >> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> >> +{
> >> + u64 start, end;
> >> + int node, pxm;
> >> +
> >> + if (srat_disabled())
> >> + return -EINVAL;
> >> +
> >> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> > Must be:
> >
> > ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
> >
> > Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>
> Hmm, I think we need to remove the check here now.
No, we might have an out-of-bound access then.
>
> There are three cases:
>
> - firmware ACPI version is consistent with the ACPICA one, then
> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>
> - firmware ACPI version is not consistent with the ACPICA one,
> for example, struct acpi_srat_mem_affinity is extended in
> new ACI version, but the formware is using the older one,
> then it's ok to use
> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
The check above is ok as we need@least struct
acpi_srat_mem_affinity as it is now.
If we later change the kernel to support multiple versions of struct
acpi_srat_mem_affinity, i.e. use data from an extended section, we
will need to add code to handle that. This will include support of
data with length < acpi_srat_mem_affinity, in this case we may not use
extended data.
>
> - but if we use the older kernel + updated new firmware,
> then
> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
> will be the case, right?
Right, and this is a valid case not resulting in an error with my
suggestion above.
>
> >
> >> + bad_srat();
> >> + return -EINVAL;
> > We need a pr_err() here to avoid that numa setup fails silently due to
> > bad fw. This applies to all error paths.
> >
> > See my delta patch below. You can merge it with your patch.
>
> Thanks! I wil merge it into next version.
Thanks,
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-27 14:01 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:01 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 27.01.16 15:12:15, Hanjun Guo wrote:
> On 2016/1/25 18:21, Robert Richter wrote:
> > On 23.01.16 17:39:20, Hanjun Guo wrote:
> >> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> >> new file mode 100644
> >> index 0000000..f7f7533
> >> --- /dev/null
> >> +++ b/arch/arm64/kernel/acpi_numa.c
> >> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> >> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> >> +{
> >> + u64 start, end;
> >> + int node, pxm;
> >> +
> >> + if (srat_disabled())
> >> + return -EINVAL;
> >> +
> >> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> > Must be:
> >
> > ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
> >
> > Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>
> Hmm, I think we need to remove the check here now.
No, we might have an out-of-bound access then.
>
> There are three cases:
>
> - firmware ACPI version is consistent with the ACPICA one, then
> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>
> - firmware ACPI version is not consistent with the ACPICA one,
> for example, struct acpi_srat_mem_affinity is extended in
> new ACI version, but the formware is using the older one,
> then it's ok to use
> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
The check above is ok as we need at least struct
acpi_srat_mem_affinity as it is now.
If we later change the kernel to support multiple versions of struct
acpi_srat_mem_affinity, i.e. use data from an extended section, we
will need to add code to handle that. This will include support of
data with length < acpi_srat_mem_affinity, in this case we may not use
extended data.
>
> - but if we use the older kernel + updated new firmware,
> then
> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
> will be the case, right?
Right, and this is a valid case not resulting in an error with my
suggestion above.
>
> >
> >> + bad_srat();
> >> + return -EINVAL;
> > We need a pr_err() here to avoid that numa setup fails silently due to
> > bad fw. This applies to all error paths.
> >
> > See my delta patch below. You can merge it with your patch.
>
> Thanks! I wil merge it into next version.
Thanks,
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-27 14:01 ` Robert Richter
(?)
@ 2016-01-28 3:16 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 3:16 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/27 22:01, Robert Richter wrote:
> On 27.01.16 15:12:15, Hanjun Guo wrote:
>> On 2016/1/25 18:21, Robert Richter wrote:
>>> On 23.01.16 17:39:20, Hanjun Guo wrote:
>>>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>>>> new file mode 100644
>>>> index 0000000..f7f7533
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/acpi_numa.c
>>>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>>>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>>> +{
>>>> + u64 start, end;
>>>> + int node, pxm;
>>>> +
>>>> + if (srat_disabled())
>>>> + return -EINVAL;
>>>> +
>>>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
>>> Must be:
>>>
>>> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>>>
>>> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>> Hmm, I think we need to remove the check here now.
> No, we might have an out-of-bound access then.
>
>> There are three cases:
>>
>> - firmware ACPI version is consistent with the ACPICA one, then
>> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>>
>> - firmware ACPI version is not consistent with the ACPICA one,
>> for example, struct acpi_srat_mem_affinity is extended in
>> new ACI version, but the formware is using the older one,
>> then it's ok to use
>> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
> The check above is ok as we need at least struct
> acpi_srat_mem_affinity as it is now.
>
> If we later change the kernel to support multiple versions of struct
> acpi_srat_mem_affinity, i.e. use data from an extended section, we
> will need to add code to handle that. This will include support of
> data with length < acpi_srat_mem_affinity, in this case we may not use
> extended data.
I checked the ACPI spec about memory affinity structure, it still have 10 bytes
reserved for future use, so I think it's safe as you suggested for next few years.
>
>> - but if we use the older kernel + updated new firmware,
>> then
>> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
>> will be the case, right?
> Right, and this is a valid case not resulting in an error with my
> suggestion above.
Yes, I just mixed up those two cases.
I will sync with Ganapat to prepare a new version and test it on x86 and
IA64 to make sure this patch set don't break anything.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-28 3:16 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 3:16 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/27 22:01, Robert Richter wrote:
> On 27.01.16 15:12:15, Hanjun Guo wrote:
>> On 2016/1/25 18:21, Robert Richter wrote:
>>> On 23.01.16 17:39:20, Hanjun Guo wrote:
>>>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>>>> new file mode 100644
>>>> index 0000000..f7f7533
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/acpi_numa.c
>>>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>>>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>>> +{
>>>> + u64 start, end;
>>>> + int node, pxm;
>>>> +
>>>> + if (srat_disabled())
>>>> + return -EINVAL;
>>>> +
>>>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
>>> Must be:
>>>
>>> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>>>
>>> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>> Hmm, I think we need to remove the check here now.
> No, we might have an out-of-bound access then.
>
>> There are three cases:
>>
>> - firmware ACPI version is consistent with the ACPICA one, then
>> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>>
>> - firmware ACPI version is not consistent with the ACPICA one,
>> for example, struct acpi_srat_mem_affinity is extended in
>> new ACI version, but the formware is using the older one,
>> then it's ok to use
>> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
> The check above is ok as we need at least struct
> acpi_srat_mem_affinity as it is now.
>
> If we later change the kernel to support multiple versions of struct
> acpi_srat_mem_affinity, i.e. use data from an extended section, we
> will need to add code to handle that. This will include support of
> data with length < acpi_srat_mem_affinity, in this case we may not use
> extended data.
I checked the ACPI spec about memory affinity structure, it still have 10 bytes
reserved for future use, so I think it's safe as you suggested for next few years.
>
>> - but if we use the older kernel + updated new firmware,
>> then
>> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
>> will be the case, right?
> Right, and this is a valid case not resulting in an error with my
> suggestion above.
Yes, I just mixed up those two cases.
I will sync with Ganapat to prepare a new version and test it on x86 and
IA64 to make sure this patch set don't break anything.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-01-28 3:16 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 3:16 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/27 22:01, Robert Richter wrote:
> On 27.01.16 15:12:15, Hanjun Guo wrote:
>> On 2016/1/25 18:21, Robert Richter wrote:
>>> On 23.01.16 17:39:20, Hanjun Guo wrote:
>>>> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
>>>> new file mode 100644
>>>> index 0000000..f7f7533
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/acpi_numa.c
>>>> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
>>>> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
>>>> +{
>>>> + u64 start, end;
>>>> + int node, pxm;
>>>> +
>>>> + if (srat_disabled())
>>>> + return -EINVAL;
>>>> +
>>>> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
>>> Must be:
>>>
>>> ma->header.length < sizeof(struct acpi_srat_mem_affinity)) {
>>>
>>> Allow extensions to struct acpi_srat_mem_affinity in newer versions.
>> Hmm, I think we need to remove the check here now.
> No, we might have an out-of-bound access then.
>
>> There are three cases:
>>
>> - firmware ACPI version is consistent with the ACPICA one, then
>> ma->header.length == sizeof(struct acpi_srat_mem_affinity )
>>
>> - firmware ACPI version is not consistent with the ACPICA one,
>> for example, struct acpi_srat_mem_affinity is extended in
>> new ACI version, but the formware is using the older one,
>> then it's ok to use
>> ma->header.length < sizeof(struct acpi_srat_mem_affinity )
> The check above is ok as we need at least struct
> acpi_srat_mem_affinity as it is now.
>
> If we later change the kernel to support multiple versions of struct
> acpi_srat_mem_affinity, i.e. use data from an extended section, we
> will need to add code to handle that. This will include support of
> data with length < acpi_srat_mem_affinity, in this case we may not use
> extended data.
I checked the ACPI spec about memory affinity structure, it still have 10 bytes
reserved for future use, so I think it's safe as you suggested for next few years.
>
>> - but if we use the older kernel + updated new firmware,
>> then
>> ma->header.length > sizeof(struct acpi_srat_mem_affinity )
>> will be the case, right?
> Right, and this is a valid case not resulting in an error with my
> suggestion above.
Yes, I just mixed up those two cases.
I will sync with Ganapat to prepare a new version and test it on x86 and
IA64 to make sure this patch set don't break anything.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-02-01 18:09 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-02-01 18:09 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:20, Hanjun Guo wrote:
> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
> {
> int ret = -ENODEV;
>
> -#ifdef CONFIG_OF_NUMA
> if (!numa_off)
> - ret = numa_init(arm64_of_numa_init);
> -#endif
> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>
> if (ret)
> numa_init(dummy_numa_init);
Ok, this style is mostly flavor, some people want #ifdefs (my
preference), some not. In any case it must build with or without the
config option set. But first some words why I like #ifdefs:
* Code is easier to understand as you don't need to look at any other
location whether it is enabled or not.
* You can't break the build if the options are not set. Thus, you
also don't need to check if the function is implemented for the
unset case (valid for the coder and also the reviewer). This makes
things a lot easier.
* Total number of lines of code that needs to be implement is
smaller.
However, if we don't ifdef the code, we need empty functions stubs in
the header file for them.
Also, the conditional assignment does not reduce the complexity of the
paths. It just concentrates everything in a single line.
How about the following (similar to x86)?
----
if (!numa_off) {
#ifdef CONFIG_ACPI_NUMA
if (!numa_init(acpi_numa_init))
return 0;
#endif
#ifdef CONFIG_OF_NUMA
if (!numa_init(of_numa_init))
return 0;
#endif
}
return numa_init(dummy_numa_init);
----
Pretty straight and nice.
Note: The !acpi_disabled check needs to be moved to the beginning of
acpi_numa_init(). Variable ret can be removed.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-02-01 18:09 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-02-01 18:09 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:20, Hanjun Guo wrote:
> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
> {
> int ret = -ENODEV;
>
> -#ifdef CONFIG_OF_NUMA
> if (!numa_off)
> - ret = numa_init(arm64_of_numa_init);
> -#endif
> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>
> if (ret)
> numa_init(dummy_numa_init);
Ok, this style is mostly flavor, some people want #ifdefs (my
preference), some not. In any case it must build with or without the
config option set. But first some words why I like #ifdefs:
* Code is easier to understand as you don't need to look at any other
location whether it is enabled or not.
* You can't break the build if the options are not set. Thus, you
also don't need to check if the function is implemented for the
unset case (valid for the coder and also the reviewer). This makes
things a lot easier.
* Total number of lines of code that needs to be implement is
smaller.
However, if we don't ifdef the code, we need empty functions stubs in
the header file for them.
Also, the conditional assignment does not reduce the complexity of the
paths. It just concentrates everything in a single line.
How about the following (similar to x86)?
----
if (!numa_off) {
#ifdef CONFIG_ACPI_NUMA
if (!numa_init(acpi_numa_init))
return 0;
#endif
#ifdef CONFIG_OF_NUMA
if (!numa_init(of_numa_init))
return 0;
#endif
}
return numa_init(dummy_numa_init);
----
Pretty straight and nice.
Note: The !acpi_disabled check needs to be moved to the beginning of
acpi_numa_init(). Variable ret can be removed.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-02-01 18:09 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-02-01 18:09 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:20, Hanjun Guo wrote:
> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
> {
> int ret = -ENODEV;
>
> -#ifdef CONFIG_OF_NUMA
> if (!numa_off)
> - ret = numa_init(arm64_of_numa_init);
> -#endif
> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>
> if (ret)
> numa_init(dummy_numa_init);
Ok, this style is mostly flavor, some people want #ifdefs (my
preference), some not. In any case it must build with or without the
config option set. But first some words why I like #ifdefs:
* Code is easier to understand as you don't need to look at any other
location whether it is enabled or not.
* You can't break the build if the options are not set. Thus, you
also don't need to check if the function is implemented for the
unset case (valid for the coder and also the reviewer). This makes
things a lot easier.
* Total number of lines of code that needs to be implement is
smaller.
However, if we don't ifdef the code, we need empty functions stubs in
the header file for them.
Also, the conditional assignment does not reduce the complexity of the
paths. It just concentrates everything in a single line.
How about the following (similar to x86)?
----
if (!numa_off) {
#ifdef CONFIG_ACPI_NUMA
if (!numa_init(acpi_numa_init))
return 0;
#endif
#ifdef CONFIG_OF_NUMA
if (!numa_init(of_numa_init))
return 0;
#endif
}
return numa_init(dummy_numa_init);
----
Pretty straight and nice.
Note: The !acpi_disabled check needs to be moved to the beginning of
acpi_numa_init(). Variable ret can be removed.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-02-01 18:09 ` Robert Richter
@ 2016-02-02 11:30 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-02-02 11:30 UTC (permalink / raw)
To: Robert Richter, Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland
On 2016/2/2 2:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
> Note: The !acpi_disabled check needs to be moved to the beginning of
> acpi_numa_init(). Variable ret can be removed.
Lorenzo suggested to remove it, Lorenzo, what's your opinion here?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-02-02 11:30 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-02-02 11:30 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/2/2 2:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
> Note: The !acpi_disabled check needs to be moved to the beginning of
> acpi_numa_init(). Variable ret can be removed.
Lorenzo suggested to remove it, Lorenzo, what's your opinion here?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-02-02 11:30 ` Hanjun Guo
@ 2016-02-02 17:00 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 100+ messages in thread
From: Lorenzo Pieralisi @ 2016-02-02 17:00 UTC (permalink / raw)
To: Hanjun Guo
Cc: Robert Richter, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, linux-acpi, linux-arm-kernel, linux-kernel,
Ganapatrao Kulkarni, Shannon Zhao, Steve Capper, Mark Rutland
On Tue, Feb 02, 2016 at 07:30:12PM +0800, Hanjun Guo wrote:
[...]
> >How about the following (similar to x86)?
> >
> >----
> > if (!numa_off) {
> >#ifdef CONFIG_ACPI_NUMA
> > if (!numa_init(acpi_numa_init))
> > return 0;
> >#endif
> >#ifdef CONFIG_OF_NUMA
> > if (!numa_init(of_numa_init))
> > return 0;
> >#endif
> > }
> >
> > return numa_init(dummy_numa_init);
> >----
> >
> >Pretty straight and nice.
> >
> >Note: The !acpi_disabled check needs to be moved to the beginning of
> >acpi_numa_init(). Variable ret can be removed.
>
> Lorenzo suggested to remove it, Lorenzo, what's your opinion here?
I do not think it is a big deal. OF is not a fall-back for ACPI,
which is what the code above may make us think, either you parse
ACPI or you parse DT.
I will have a look at the complete code to check if we can rewrite
it differently but I would not be too worried about it.
Lorenzo
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-02-02 17:00 ` Lorenzo Pieralisi
0 siblings, 0 replies; 100+ messages in thread
From: Lorenzo Pieralisi @ 2016-02-02 17:00 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Feb 02, 2016 at 07:30:12PM +0800, Hanjun Guo wrote:
[...]
> >How about the following (similar to x86)?
> >
> >----
> > if (!numa_off) {
> >#ifdef CONFIG_ACPI_NUMA
> > if (!numa_init(acpi_numa_init))
> > return 0;
> >#endif
> >#ifdef CONFIG_OF_NUMA
> > if (!numa_init(of_numa_init))
> > return 0;
> >#endif
> > }
> >
> > return numa_init(dummy_numa_init);
> >----
> >
> >Pretty straight and nice.
> >
> >Note: The !acpi_disabled check needs to be moved to the beginning of
> >acpi_numa_init(). Variable ret can be removed.
>
> Lorenzo suggested to remove it, Lorenzo, what's your opinion here?
I do not think it is a big deal. OF is not a fall-back for ACPI,
which is what the code above may make us think, either you parse
ACPI or you parse DT.
I will have a look at the complete code to check if we can rewrite
it differently but I would not be too worried about it.
Lorenzo
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-02-01 18:09 ` Robert Richter
@ 2016-03-02 14:10 ` Matthias Brugger
-1 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:10 UTC (permalink / raw)
To: Robert Richter, Hanjun Guo
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, Rafael J. Wysocki,
Will Deacon, linux-kernel, linux-acpi, Shannon Zhao,
Catalin Marinas, Ganapatrao Kulkarni, linux-arm-kernel,
Hanjun Guo
On 01/02/16 19:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
And it solves a compilation error if CONFIG_ACPI is not set and
therefore asm/acpi.h is not included in linux/acpi.h
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-03-02 14:10 ` Matthias Brugger
0 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:10 UTC (permalink / raw)
To: linux-arm-kernel
On 01/02/16 19:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
And it solves a compilation error if CONFIG_ACPI is not set and
therefore asm/acpi.h is not included in linux/acpi.h
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-02-01 18:09 ` Robert Richter
@ 2016-03-02 14:10 ` Matthias Brugger
-1 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:10 UTC (permalink / raw)
To: Robert Richter, Hanjun Guo
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, Rafael J. Wysocki,
Will Deacon, linux-kernel, linux-acpi, Shannon Zhao,
Catalin Marinas, Ganapatrao Kulkarni, linux-arm-kernel,
Hanjun Guo
On 01/02/16 19:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
And it solves a compilation error if CONFIG_ACPI is not set and
therefore asm/acpi.h is not included in linux/acpi.h
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-03-02 14:10 ` Matthias Brugger
0 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:10 UTC (permalink / raw)
To: linux-arm-kernel
On 01/02/16 19:09, Robert Richter wrote:
> On 23.01.16 17:39:20, Hanjun Guo wrote:
>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
>>
>> if (ret)
>> numa_init(dummy_numa_init);
>
> Ok, this style is mostly flavor, some people want #ifdefs (my
> preference), some not. In any case it must build with or without the
> config option set. But first some words why I like #ifdefs:
>
> * Code is easier to understand as you don't need to look at any other
> location whether it is enabled or not.
>
> * You can't break the build if the options are not set. Thus, you
> also don't need to check if the function is implemented for the
> unset case (valid for the coder and also the reviewer). This makes
> things a lot easier.
>
> * Total number of lines of code that needs to be implement is
> smaller.
>
> However, if we don't ifdef the code, we need empty functions stubs in
> the header file for them.
>
> Also, the conditional assignment does not reduce the complexity of the
> paths. It just concentrates everything in a single line.
>
> How about the following (similar to x86)?
>
> ----
> if (!numa_off) {
> #ifdef CONFIG_ACPI_NUMA
> if (!numa_init(acpi_numa_init))
> return 0;
> #endif
> #ifdef CONFIG_OF_NUMA
> if (!numa_init(of_numa_init))
> return 0;
> #endif
> }
>
> return numa_init(dummy_numa_init);
> ----
>
> Pretty straight and nice.
>
And it solves a compilation error if CONFIG_ACPI is not set and
therefore asm/acpi.h is not included in linux/acpi.h
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-01-23 9:39 ` Hanjun Guo
@ 2016-03-02 14:08 ` Matthias Brugger
-1 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:08 UTC (permalink / raw)
To: Hanjun Guo, Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, linux-kernel,
Robert Richter, linux-acpi, Shannon Zhao, Ganapatrao Kulkarni,
linux-arm-kernel, Hanjun Guo
On 23/01/16 10:39, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce a new file to hold ACPI based NUMA information
> parsing from SRAT and SLIT.
>
> SRAT includes the CPU ACPI ID to Proximity Domain mappings
> and memory ranges to Proximity Domain mapping.
> SLIT has the information of inter node
> distances(relative number for access latency).
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
> ---
> arch/arm64/include/asm/acpi.h | 8 ++
> arch/arm64/include/asm/numa.h | 3 +
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 3 +
> arch/arm64/mm/numa.c | 5 +-
> 6 files changed, 252 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm64/kernel/acpi_numa.c
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index caafd63..6db9c6f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
> #endif
>
> +#ifdef CONFIG_ACPI_NUMA
> +int arm64_acpi_numa_init(void);
> +void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
> +#else
> +static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
> +static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
> +#endif /* CONFIG_ACPI_NUMA */
> +
> #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> index 54deb38..1beb194 100644
> --- a/arch/arm64/include/asm/numa.h
> +++ b/arch/arm64/include/asm/numa.h
> @@ -6,6 +6,8 @@
>
> #ifdef CONFIG_NUMA
>
> +#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
> +
> /* currently, arm64 implements flat NUMA topology */
> #define parent_node(node) (node)
>
> @@ -43,6 +45,7 @@ struct device_node;
> int __init arm64_of_numa_init(void);
> void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
> #else
> +static inline int arm64_of_numa_init(void) { return -ENODEV; }
> static inline void of_numa_set_node_info(unsigned int cpu,
> struct device_node *dn) { }
> #endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 7987763..555c4a5 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> arm64-obj-$(CONFIG_ACPI) += acpi.o
> arm64-obj-$(CONFIG_OF_NUMA) += of_numa.o
> +arm64-obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
>
> obj-y += $(arm64-obj-y) vdso/
> obj-m += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c
> @@ -0,0 +1,235 @@
> +/*
> + * ACPI 5.1 based NUMA setup for ARM64
> + * Lots of code was borrowed from arch/x86/mm/srat.c
> + *
> + * Copyright 2004 Andi Kleen, SuSE Labs.
> + * Copyright (C) 2013-2016, Linaro Ltd.
> + * Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
> + *
> + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
> + * Assumes all memory regions belonging to a single proximity domain
> + * are in one chunk. Holes between them will be included in the node.
> + */
> +
> +#define pr_fmt(fmt) "ACPI: NUMA: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/bitmap.h>
> +#include <linux/bootmem.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/memblock.h>
> +#include <linux/mmzone.h>
> +#include <linux/module.h>
> +#include <linux/topology.h>
> +
> +#include <acpi/processor.h>
> +#include <asm/numa.h>
> +
> +int acpi_numa __initdata;
> +static int cpus_in_srat;
> +
> +struct __node_cpu_hwid {
> + u32 node_id; /* logical node containing this CPU */
> + u64 cpu_hwid; /* MPIDR for this CPU */
> +};
> +
> +static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
> +[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
> +
> +static __init void bad_srat(void)
> +{
> + pr_err("SRAT not used.\n");
> + acpi_numa = -1;
> +}
> +
> +static __init inline int srat_disabled(void)
> +{
> + return acpi_numa < 0;
> +}
> +
> +void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
> +{
> + int nid = 0, i;
> +
> + for (i = 0; i < cpus_in_srat; i++) {
> + if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
> + nid = early_node_cpu_hwid[i].node_id;
> + break;
> + }
> + }
> +
> + cpu_to_node_map[cpu] = nid;
> +}
> +
> +/*
> + * Callback for SLIT parsing.
> + * It will get the distance information presented by SLIT
> + * and init the distance matrix of numa nodes
> + */
> +void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> +{
> + int i, j;
> +
> + for (i = 0; i < slit->locality_count; i++) {
> + const int from_node = pxm_to_node(i);
> +
> + if (from_node == NUMA_NO_NODE)
> + continue;
> +
> + for (j = 0; j < slit->locality_count; j++) {
> + const int to_node = pxm_to_node(j);
> +
> + if (to_node == NUMA_NO_NODE)
> + continue;
> +
> + pr_debug("SLIT: Distance[%d][%d] = %d\n",
> + from_node, to_node,
> + slit->entry[
> + slit->locality_count * i + j]);
> + numa_set_distance(from_node, to_node,
> + slit->entry[slit->locality_count * i + j]);
> + }
> + }
> +}
> +
> +static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
> +{
> + unsigned long madt_end, entry;
> + struct acpi_table_madt *madt;
> + acpi_size tbl_size;
> +
> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt, &tbl_size)))
> + return -ENODEV;
> +
> + entry = (unsigned long)madt;
> + madt_end = entry + madt->header.length;
> +
> + /* Parse all entries looking for a match. */
> + entry += sizeof(struct acpi_table_madt);
> + while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
> + struct acpi_subtable_header *header =
> + (struct acpi_subtable_header *)entry;
> +
> + if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
> + struct acpi_madt_generic_interrupt *gicc =
> + container_of(header,
> + struct acpi_madt_generic_interrupt, header);
> +
> + if ((gicc->flags & ACPI_MADT_ENABLED) &&
> + (gicc->uid == acpi_id)) {
> + *mpidr = gicc->arm_mpidr;
> + early_acpi_os_unmap_memory(madt, tbl_size);
> + return 0;
> + }
> + }
> + entry += header->length;
> + }
> +
> + early_acpi_os_unmap_memory(madt, tbl_size);
> + return -ENODEV;
> +}
> +
> +/* Callback for Proximity Domain -> ACPI processor UID mapping */
> +void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
> +{
> + int pxm, node;
> + u64 mpidr;
> +
> + if (srat_disabled())
> + return;
> +
> + if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
> + bad_srat();
> + return;
> + }
> +
> + if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
> + return;
> +
> + if (cpus_in_srat >= NR_CPUS) {
> + pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
> + NR_CPUS);
> + return;
> + }
> +
> + pxm = pa->proximity_domain;
> + node = acpi_map_pxm_to_node(pxm);
> +
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains %d\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
> + pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
> + pxm, pa->acpi_processor_uid);
> + bad_srat();
> + return;
> + }
> +
> + early_node_cpu_hwid[cpus_in_srat].node_id = node;
> + early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
> + node_set(node, numa_nodes_parsed);
> + acpi_numa = 1;
> + cpus_in_srat++;
> + pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
> + pxm, mpidr, node, cpus_in_srat);
> +}
> +
> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> + u64 start, end;
> + int node, pxm;
> +
> + if (srat_disabled())
> + return -EINVAL;
> +
> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + /* Ignore disabled entries */
> + if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
> + return -EINVAL;
> +
> + start = ma->base_address;
> + end = start + ma->length;
> + pxm = ma->proximity_domain;
> +
> + node = acpi_map_pxm_to_node(pxm);
> +
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains.\n");
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> + node, pxm,
> + (unsigned long long) start, (unsigned long long) end - 1);
> +
> + if (numa_add_memblk(node, start, (end - start)) < 0) {
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int __init arm64_acpi_numa_init(void)
> +{
> + int ret;
> +
> + ret = acpi_numa_init();
> + if (ret)
> + return ret;
> +
> + return srat_disabled() ? -EINVAL : 0;
> +}
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index a2a8c2d..112a892 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> /* map the logical cpu id to cpu MPIDR */
> cpu_logical_map(cpu_count) = hwid;
>
> + /* map logical cpu to node */
> + acpi_numa_set_node_info(cpu_count, hwid);
> +
> cpu_count++;
> }
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 9e8704b..e974995 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -17,6 +17,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi.h>
> #include <linux/bootmem.h>
> #include <linux/ctype.h>
> #include <linux/init.h>
> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
> {
> int ret = -ENODEV;
>
> -#ifdef CONFIG_OF_NUMA
> if (!numa_off)
> - ret = numa_init(arm64_of_numa_init);
> -#endif
> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
Header asm/acpi.h is included in linux/acpi.h but only if CONFIG_ACPI=y
arm64_acpi_numa_init is declared in asm/acpi.h, so if we don't use the
ifdef CONFIG_* approach from Robert, we will need to include as/acpi.h
implicitly here. Otherwise we get a compilation error if CONFIG_ACPI is
not set.
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-03-02 14:08 ` Matthias Brugger
0 siblings, 0 replies; 100+ messages in thread
From: Matthias Brugger @ 2016-03-02 14:08 UTC (permalink / raw)
To: linux-arm-kernel
On 23/01/16 10:39, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Introduce a new file to hold ACPI based NUMA information
> parsing from SRAT and SLIT.
>
> SRAT includes the CPU ACPI ID to Proximity Domain mappings
> and memory ranges to Proximity Domain mapping.
> SLIT has the information of inter node
> distances(relative number for access latency).
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
> ---
> arch/arm64/include/asm/acpi.h | 8 ++
> arch/arm64/include/asm/numa.h | 3 +
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/acpi_numa.c | 235 ++++++++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 3 +
> arch/arm64/mm/numa.c | 5 +-
> 6 files changed, 252 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm64/kernel/acpi_numa.c
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index caafd63..6db9c6f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -96,4 +96,12 @@ static inline const char *acpi_get_enable_method(int cpu)
> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
> #endif
>
> +#ifdef CONFIG_ACPI_NUMA
> +int arm64_acpi_numa_init(void);
> +void acpi_numa_set_node_info(unsigned int cpu, u64 hwid);
> +#else
> +static inline int arm64_acpi_numa_init(void) { return -ENODEV; }
> +static inline void acpi_numa_set_node_info(unsigned int cpu, u64 hwid) { }
> +#endif /* CONFIG_ACPI_NUMA */
> +
> #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
> index 54deb38..1beb194 100644
> --- a/arch/arm64/include/asm/numa.h
> +++ b/arch/arm64/include/asm/numa.h
> @@ -6,6 +6,8 @@
>
> #ifdef CONFIG_NUMA
>
> +#define NR_NODE_MEMBLKS (MAX_NUMNODES * 2)
> +
> /* currently, arm64 implements flat NUMA topology */
> #define parent_node(node) (node)
>
> @@ -43,6 +45,7 @@ struct device_node;
> int __init arm64_of_numa_init(void);
> void __init of_numa_set_node_info(unsigned int cpu, struct device_node *dn);
> #else
> +static inline int arm64_of_numa_init(void) { return -ENODEV; }
> static inline void of_numa_set_node_info(unsigned int cpu,
> struct device_node *dn) { }
> #endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 7987763..555c4a5 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -42,6 +42,7 @@ arm64-obj-$(CONFIG_PCI) += pci.o
> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> arm64-obj-$(CONFIG_ACPI) += acpi.o
> arm64-obj-$(CONFIG_OF_NUMA) += of_numa.o
> +arm64-obj-$(CONFIG_ACPI_NUMA) += acpi_numa.o
>
> obj-y += $(arm64-obj-y) vdso/
> obj-m += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
> new file mode 100644
> index 0000000..f7f7533
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi_numa.c
> @@ -0,0 +1,235 @@
> +/*
> + * ACPI 5.1 based NUMA setup for ARM64
> + * Lots of code was borrowed from arch/x86/mm/srat.c
> + *
> + * Copyright 2004 Andi Kleen, SuSE Labs.
> + * Copyright (C) 2013-2016, Linaro Ltd.
> + * Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + * Reads the ACPI SRAT table to figure out what memory belongs to which CPUs.
> + *
> + * Called from acpi_numa_init while reading the SRAT and SLIT tables.
> + * Assumes all memory regions belonging to a single proximity domain
> + * are in one chunk. Holes between them will be included in the node.
> + */
> +
> +#define pr_fmt(fmt) "ACPI: NUMA: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/bitmap.h>
> +#include <linux/bootmem.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/memblock.h>
> +#include <linux/mmzone.h>
> +#include <linux/module.h>
> +#include <linux/topology.h>
> +
> +#include <acpi/processor.h>
> +#include <asm/numa.h>
> +
> +int acpi_numa __initdata;
> +static int cpus_in_srat;
> +
> +struct __node_cpu_hwid {
> + u32 node_id; /* logical node containing this CPU */
> + u64 cpu_hwid; /* MPIDR for this CPU */
> +};
> +
> +static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
> +[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
> +
> +static __init void bad_srat(void)
> +{
> + pr_err("SRAT not used.\n");
> + acpi_numa = -1;
> +}
> +
> +static __init inline int srat_disabled(void)
> +{
> + return acpi_numa < 0;
> +}
> +
> +void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
> +{
> + int nid = 0, i;
> +
> + for (i = 0; i < cpus_in_srat; i++) {
> + if (hwid == early_node_cpu_hwid[i].cpu_hwid) {
> + nid = early_node_cpu_hwid[i].node_id;
> + break;
> + }
> + }
> +
> + cpu_to_node_map[cpu] = nid;
> +}
> +
> +/*
> + * Callback for SLIT parsing.
> + * It will get the distance information presented by SLIT
> + * and init the distance matrix of numa nodes
> + */
> +void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
> +{
> + int i, j;
> +
> + for (i = 0; i < slit->locality_count; i++) {
> + const int from_node = pxm_to_node(i);
> +
> + if (from_node == NUMA_NO_NODE)
> + continue;
> +
> + for (j = 0; j < slit->locality_count; j++) {
> + const int to_node = pxm_to_node(j);
> +
> + if (to_node == NUMA_NO_NODE)
> + continue;
> +
> + pr_debug("SLIT: Distance[%d][%d] = %d\n",
> + from_node, to_node,
> + slit->entry[
> + slit->locality_count * i + j]);
> + numa_set_distance(from_node, to_node,
> + slit->entry[slit->locality_count * i + j]);
> + }
> + }
> +}
> +
> +static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
> +{
> + unsigned long madt_end, entry;
> + struct acpi_table_madt *madt;
> + acpi_size tbl_size;
> +
> + if (ACPI_FAILURE(acpi_get_table_with_size(ACPI_SIG_MADT, 0,
> + (struct acpi_table_header **)&madt, &tbl_size)))
> + return -ENODEV;
> +
> + entry = (unsigned long)madt;
> + madt_end = entry + madt->header.length;
> +
> + /* Parse all entries looking for a match. */
> + entry += sizeof(struct acpi_table_madt);
> + while (entry + sizeof(struct acpi_subtable_header) < madt_end) {
> + struct acpi_subtable_header *header =
> + (struct acpi_subtable_header *)entry;
> +
> + if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
> + struct acpi_madt_generic_interrupt *gicc =
> + container_of(header,
> + struct acpi_madt_generic_interrupt, header);
> +
> + if ((gicc->flags & ACPI_MADT_ENABLED) &&
> + (gicc->uid == acpi_id)) {
> + *mpidr = gicc->arm_mpidr;
> + early_acpi_os_unmap_memory(madt, tbl_size);
> + return 0;
> + }
> + }
> + entry += header->length;
> + }
> +
> + early_acpi_os_unmap_memory(madt, tbl_size);
> + return -ENODEV;
> +}
> +
> +/* Callback for Proximity Domain -> ACPI processor UID mapping */
> +void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
> +{
> + int pxm, node;
> + u64 mpidr;
> +
> + if (srat_disabled())
> + return;
> +
> + if (pa->header.length < sizeof(struct acpi_srat_gicc_affinity)) {
> + bad_srat();
> + return;
> + }
> +
> + if (!(pa->flags & ACPI_SRAT_GICC_ENABLED))
> + return;
> +
> + if (cpus_in_srat >= NR_CPUS) {
> + pr_warn_once("SRAT: cpu_to_node_map[%d] is too small, may not be able to use all cpus\n",
> + NR_CPUS);
> + return;
> + }
> +
> + pxm = pa->proximity_domain;
> + node = acpi_map_pxm_to_node(pxm);
> +
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains %d\n", pxm);
> + bad_srat();
> + return;
> + }
> +
> + if (get_mpidr_in_madt(pa->acpi_processor_uid, &mpidr)) {
> + pr_warn("SRAT: PXM %d with ACPI ID %d has no valid MPIDR in MADT\n",
> + pxm, pa->acpi_processor_uid);
> + bad_srat();
> + return;
> + }
> +
> + early_node_cpu_hwid[cpus_in_srat].node_id = node;
> + early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
> + node_set(node, numa_nodes_parsed);
> + acpi_numa = 1;
> + cpus_in_srat++;
> + pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
> + pxm, mpidr, node, cpus_in_srat);
> +}
> +
> +/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
> +int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
> +{
> + u64 start, end;
> + int node, pxm;
> +
> + if (srat_disabled())
> + return -EINVAL;
> +
> + if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + /* Ignore disabled entries */
> + if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
> + return -EINVAL;
> +
> + start = ma->base_address;
> + end = start + ma->length;
> + pxm = ma->proximity_domain;
> +
> + node = acpi_map_pxm_to_node(pxm);
> +
> + if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
> + pr_err("SRAT: Too many proximity domains.\n");
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
> + node, pxm,
> + (unsigned long long) start, (unsigned long long) end - 1);
> +
> + if (numa_add_memblk(node, start, (end - start)) < 0) {
> + bad_srat();
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int __init arm64_acpi_numa_init(void)
> +{
> + int ret;
> +
> + ret = acpi_numa_init();
> + if (ret)
> + return ret;
> +
> + return srat_disabled() ? -EINVAL : 0;
> +}
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index a2a8c2d..112a892 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -447,6 +447,9 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> /* map the logical cpu id to cpu MPIDR */
> cpu_logical_map(cpu_count) = hwid;
>
> + /* map logical cpu to node */
> + acpi_numa_set_node_info(cpu_count, hwid);
> +
> cpu_count++;
> }
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index 9e8704b..e974995 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -17,6 +17,7 @@
> * along with this program. If not, see <http://www.gnu.org/licenses/>.
> */
>
> +#include <linux/acpi.h>
> #include <linux/bootmem.h>
> #include <linux/ctype.h>
> #include <linux/init.h>
> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
> {
> int ret = -ENODEV;
>
> -#ifdef CONFIG_OF_NUMA
> if (!numa_off)
> - ret = numa_init(arm64_of_numa_init);
> -#endif
> + ret = numa_init(acpi_disabled ? arm64_of_numa_init : arm64_acpi_numa_init);
Header asm/acpi.h is included in linux/acpi.h but only if CONFIG_ACPI=y
arm64_acpi_numa_init is declared in asm/acpi.h, so if we don't use the
ifdef CONFIG_* approach from Robert, we will need to include as/acpi.h
implicitly here. Otherwise we get a compilation error if CONFIG_ACPI is
not set.
Regards,
Matthias
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
2016-03-02 14:08 ` Matthias Brugger
@ 2016-03-10 9:50 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-03-10 9:50 UTC (permalink / raw)
To: Matthias Brugger, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, linux-kernel,
Robert Richter, linux-acpi, Shannon Zhao, Ganapatrao Kulkarni,
linux-arm-kernel
Hi Matthias,
Sorry for the late reply, on a travelling now.
On 03/02/2016 10:08 PM, Matthias Brugger wrote:
>
>
> On 23/01/16 10:39, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> Introduce a new file to hold ACPI based NUMA information
>> parsing from SRAT and SLIT.
>>
>> SRAT includes the CPU ACPI ID to Proximity Domain mappings
>> and memory ranges to Proximity Domain mapping.
>> SLIT has the information of inter node
>> distances(relative number for access latency).
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
[..]
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 9e8704b..e974995 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -17,6 +17,7 @@
>> * along with this program. If not, see
>> <http://www.gnu.org/licenses/>.
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/bootmem.h>
>> #include <linux/ctype.h>
>> #include <linux/init.h>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init :
>> arm64_acpi_numa_init);
>
> Header asm/acpi.h is included in linux/acpi.h but only if CONFIG_ACPI=y
> arm64_acpi_numa_init is declared in asm/acpi.h, so if we don't use the
> ifdef CONFIG_* approach from Robert, we will need to include as/acpi.h
> implicitly here. Otherwise we get a compilation error if CONFIG_ACPI is
> not set.
Yes, I noticed the same issue as you spotted out, and I agree with
you and Robert that I should use the ifdef CONFIG_* approach.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT
@ 2016-03-10 9:50 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-03-10 9:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Matthias,
Sorry for the late reply, on a travelling now.
On 03/02/2016 10:08 PM, Matthias Brugger wrote:
>
>
> On 23/01/16 10:39, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> Introduce a new file to hold ACPI based NUMA information
>> parsing from SRAT and SLIT.
>>
>> SRAT includes the CPU ACPI ID to Proximity Domain mappings
>> and memory ranges to Proximity Domain mapping.
>> SLIT has the information of inter node
>> distances(relative number for access latency).
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
[..]
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 9e8704b..e974995 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -17,6 +17,7 @@
>> * along with this program. If not, see
>> <http://www.gnu.org/licenses/>.
>> */
>>
>> +#include <linux/acpi.h>
>> #include <linux/bootmem.h>
>> #include <linux/ctype.h>
>> #include <linux/init.h>
>> @@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
>> {
>> int ret = -ENODEV;
>>
>> -#ifdef CONFIG_OF_NUMA
>> if (!numa_off)
>> - ret = numa_init(arm64_of_numa_init);
>> -#endif
>> + ret = numa_init(acpi_disabled ? arm64_of_numa_init :
>> arm64_acpi_numa_init);
>
> Header asm/acpi.h is included in linux/acpi.h but only if CONFIG_ACPI=y
> arm64_acpi_numa_init is declared in asm/acpi.h, so if we don't use the
> ifdef CONFIG_* approach from Robert, we will need to include as/acpi.h
> implicitly here. Otherwise we get a compilation error if CONFIG_ACPI is
> not set.
Yes, I noticed the same issue as you spotted out, and I agree with
you and Robert that I should use the ifdef CONFIG_* approach.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Add function needed for cpu to node mapping, and enable
ACPI based NUMA for ARM64 in Kconfig
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/Kconfig | 2 +-
drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 17 ++++++++++++++++-
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d6d5749..31875ab 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -283,7 +283,7 @@ config ACPI_THERMAL
config ACPI_NUMA
bool "NUMA support"
depends on NUMA
- depends on (X86 || IA64)
+ depends on (X86 || IA64 || ARM64)
default y if IA64_GENERIC || IA64_SGI_SN2
config ACPI_CUSTOM_DSDT_FILE
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 2de6068..4728525 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -167,6 +167,18 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
}
break;
+ case ACPI_SRAT_TYPE_GICC_AFFINITY:
+ {
+ struct acpi_srat_gicc_affinity *p =
+ (struct acpi_srat_gicc_affinity *)header;
+ pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+ }
+ break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
@@ -252,6 +264,24 @@ acpi_parse_processor_affinity(struct acpi_subtable_header *header,
return 0;
}
+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_srat_gicc_affinity *processor_affinity;
+
+ processor_affinity = (struct acpi_srat_gicc_affinity *)header;
+ if (!processor_affinity)
+ return -EINVAL;
+
+ acpi_table_print_srat_entry(header);
+
+ /* let architecture-dependent part to do it */
+ acpi_numa_gicc_affinity_init(processor_affinity);
+
+ return 0;
+}
+
static int __initdata parsed_numa_memblks;
static int __init
@@ -296,6 +326,9 @@ int __init acpi_numa_init(void)
{
int cnt = 0;
+ if (acpi_disabled)
+ return -EINVAL;
+
/*
* Should not limit number with cpu num that is from NR_CPUS or nr_cpus=
* SRAT cpu entries could have different order with that in MADT.
@@ -308,6 +341,8 @@ int __init acpi_numa_init(void)
acpi_parse_x2apic_affinity, 0);
acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
acpi_parse_processor_affinity, 0);
+ acpi_table_parse_srat(ACPI_SRAT_TYPE_GICC_AFFINITY,
+ acpi_parse_gicc_affinity, 0);
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity,
NR_NODE_MEMBLKS);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 574d829..e386ae2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -168,10 +168,25 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
int acpi_parse_mcfg (struct acpi_table_header *header);
void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
-/* the following four functions are architecture-dependent */
+/* the following numa functions are architecture-dependent */
void acpi_numa_slit_init (struct acpi_table_slit *slit);
+
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
+#else
+static inline void
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) { }
+#endif
+
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
+
+#ifdef CONFIG_ARM64
+void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
+#else
+static inline void
+acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
+#endif
+
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Add function needed for cpu to node mapping, and enable
ACPI based NUMA for ARM64 in Kconfig
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/Kconfig | 2 +-
drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 17 ++++++++++++++++-
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d6d5749..31875ab 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -283,7 +283,7 @@ config ACPI_THERMAL
config ACPI_NUMA
bool "NUMA support"
depends on NUMA
- depends on (X86 || IA64)
+ depends on (X86 || IA64 || ARM64)
default y if IA64_GENERIC || IA64_SGI_SN2
config ACPI_CUSTOM_DSDT_FILE
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 2de6068..4728525 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -167,6 +167,18 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
}
break;
+ case ACPI_SRAT_TYPE_GICC_AFFINITY:
+ {
+ struct acpi_srat_gicc_affinity *p =
+ (struct acpi_srat_gicc_affinity *)header;
+ pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+ }
+ break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
@@ -252,6 +264,24 @@ acpi_parse_processor_affinity(struct acpi_subtable_header *header,
return 0;
}
+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_srat_gicc_affinity *processor_affinity;
+
+ processor_affinity = (struct acpi_srat_gicc_affinity *)header;
+ if (!processor_affinity)
+ return -EINVAL;
+
+ acpi_table_print_srat_entry(header);
+
+ /* let architecture-dependent part to do it */
+ acpi_numa_gicc_affinity_init(processor_affinity);
+
+ return 0;
+}
+
static int __initdata parsed_numa_memblks;
static int __init
@@ -296,6 +326,9 @@ int __init acpi_numa_init(void)
{
int cnt = 0;
+ if (acpi_disabled)
+ return -EINVAL;
+
/*
* Should not limit number with cpu num that is from NR_CPUS or nr_cpus=
* SRAT cpu entries could have different order with that in MADT.
@@ -308,6 +341,8 @@ int __init acpi_numa_init(void)
acpi_parse_x2apic_affinity, 0);
acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
acpi_parse_processor_affinity, 0);
+ acpi_table_parse_srat(ACPI_SRAT_TYPE_GICC_AFFINITY,
+ acpi_parse_gicc_affinity, 0);
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity,
NR_NODE_MEMBLKS);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 574d829..e386ae2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -168,10 +168,25 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
int acpi_parse_mcfg (struct acpi_table_header *header);
void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
-/* the following four functions are architecture-dependent */
+/* the following numa functions are architecture-dependent */
void acpi_numa_slit_init (struct acpi_table_slit *slit);
+
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
+#else
+static inline void
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) { }
+#endif
+
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
+
+#ifdef CONFIG_ARM64
+void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
+#else
+static inline void
+acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
+#endif
+
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Add function needed for cpu to node mapping, and enable
ACPI based NUMA for ARM64 in Kconfig
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/Kconfig | 2 +-
drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 17 ++++++++++++++++-
3 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index d6d5749..31875ab 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -283,7 +283,7 @@ config ACPI_THERMAL
config ACPI_NUMA
bool "NUMA support"
depends on NUMA
- depends on (X86 || IA64)
+ depends on (X86 || IA64 || ARM64)
default y if IA64_GENERIC || IA64_SGI_SN2
config ACPI_CUSTOM_DSDT_FILE
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 2de6068..4728525 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -167,6 +167,18 @@ acpi_table_print_srat_entry(struct acpi_subtable_header *header)
}
break;
+ case ACPI_SRAT_TYPE_GICC_AFFINITY:
+ {
+ struct acpi_srat_gicc_affinity *p =
+ (struct acpi_srat_gicc_affinity *)header;
+ pr_debug("SRAT Processor (acpi id[0x%04x]) in proximity domain %d %s\n",
+ p->acpi_processor_uid,
+ p->proximity_domain,
+ (p->flags & ACPI_SRAT_GICC_ENABLED) ?
+ "enabled" : "disabled");
+ }
+ break;
+
default:
pr_warn("Found unsupported SRAT entry (type = 0x%x)\n",
header->type);
@@ -252,6 +264,24 @@ acpi_parse_processor_affinity(struct acpi_subtable_header *header,
return 0;
}
+static int __init
+acpi_parse_gicc_affinity(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_srat_gicc_affinity *processor_affinity;
+
+ processor_affinity = (struct acpi_srat_gicc_affinity *)header;
+ if (!processor_affinity)
+ return -EINVAL;
+
+ acpi_table_print_srat_entry(header);
+
+ /* let architecture-dependent part to do it */
+ acpi_numa_gicc_affinity_init(processor_affinity);
+
+ return 0;
+}
+
static int __initdata parsed_numa_memblks;
static int __init
@@ -296,6 +326,9 @@ int __init acpi_numa_init(void)
{
int cnt = 0;
+ if (acpi_disabled)
+ return -EINVAL;
+
/*
* Should not limit number with cpu num that is from NR_CPUS or nr_cpus=
* SRAT cpu entries could have different order with that in MADT.
@@ -308,6 +341,8 @@ int __init acpi_numa_init(void)
acpi_parse_x2apic_affinity, 0);
acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
acpi_parse_processor_affinity, 0);
+ acpi_table_parse_srat(ACPI_SRAT_TYPE_GICC_AFFINITY,
+ acpi_parse_gicc_affinity, 0);
cnt = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity,
NR_NODE_MEMBLKS);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 574d829..e386ae2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -168,10 +168,25 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
int acpi_parse_mcfg (struct acpi_table_header *header);
void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
-/* the following four functions are architecture-dependent */
+/* the following numa functions are architecture-dependent */
void acpi_numa_slit_init (struct acpi_table_slit *slit);
+
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
+#else
+static inline void
+acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa) { }
+#endif
+
void acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa);
+
+#ifdef CONFIG_ARM64
+void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
+#else
+static inline void
+acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
+#endif
+
int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
#ifdef CONFIG_ACPI_HAS_NUMA_ARCH_FIXUP
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-29 16:37 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-29 16:37 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Add function needed for cpu to node mapping, and enable
> ACPI based NUMA for ARM64 in Kconfig
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/Kconfig | 2 +-
> drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 17 ++++++++++++++++-
> 3 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index d6d5749..31875ab 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -283,7 +283,7 @@ config ACPI_THERMAL
> config ACPI_NUMA
> bool "NUMA support"
> depends on NUMA
> - depends on (X86 || IA64)
> + depends on (X86 || IA64 || ARM64)
> default y if IA64_GENERIC || IA64_SGI_SN2
This should be default enabled here for arm64 to have it enabled with
NUMA.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
@ 2016-01-29 16:37 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-29 16:37 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Add function needed for cpu to node mapping, and enable
> ACPI based NUMA for ARM64 in Kconfig
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/Kconfig | 2 +-
> drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 17 ++++++++++++++++-
> 3 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index d6d5749..31875ab 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -283,7 +283,7 @@ config ACPI_THERMAL
> config ACPI_NUMA
> bool "NUMA support"
> depends on NUMA
> - depends on (X86 || IA64)
> + depends on (X86 || IA64 || ARM64)
> default y if IA64_GENERIC || IA64_SGI_SN2
This should be default enabled here for arm64 to have it enabled with
NUMA.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 06/12] acpi, numa: Enable ACPI based NUMA on ARM64
@ 2016-01-29 16:37 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-29 16:37 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:21, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Add function needed for cpu to node mapping, and enable
> ACPI based NUMA for ARM64 in Kconfig
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> drivers/acpi/Kconfig | 2 +-
> drivers/acpi/numa.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 17 ++++++++++++++++-
> 3 files changed, 52 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index d6d5749..31875ab 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -283,7 +283,7 @@ config ACPI_THERMAL
> config ACPI_NUMA
> bool "NUMA support"
> depends on NUMA
> - depends on (X86 || IA64)
> + depends on (X86 || IA64 || ARM64)
> default y if IA64_GENERIC || IA64_SGI_SN2
This should be default enabled here for arm64 to have it enabled with
NUMA.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 07/12] acpi, numa: move acpi_numa_slit_init() to common place
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_slit_init() is used by both x86 and arm64, and
the code is the same, move it to common place to simplify
the code, and mark it as __weak because the different
implimentation for ia64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 31 -------------------------------
arch/x86/mm/srat.c | 27 ---------------------------
drivers/acpi/numa.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 30 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533..15fb935 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -64,37 +64,6 @@ void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
cpu_to_node_map[cpu] = nid;
}
-/*
- * Callback for SLIT parsing.
- * It will get the distance information presented by SLIT
- * and init the distance matrix of numa nodes
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- pr_debug("SLIT: Distance[%d][%d] = %d\n",
- from_node, to_node,
- slit->entry[
- slit->locality_count * i + j]);
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
{
unsigned long madt_end, entry;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 9fa1746..92a640a 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -42,33 +42,6 @@ static __init inline int srat_disabled(void)
return acpi_numa < 0;
}
-/*
- * Callback for SLIT parsing. pxm_to_node() returns NUMA_NO_NODE for
- * I/O localities since SRAT does not list them. I/O localities are
- * not supported at this point.
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4728525..b33915e 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -209,6 +209,36 @@ static int __init slit_valid(struct acpi_table_slit *slit)
return 1;
}
+/*
+ * Callback for SLIT parsing. It will get the distance information
+ * presented by SLIT and init the distance matrix of numa nodes
+ */
+void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 07/12] acpi, numa: move acpi_numa_slit_init() to common place
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_slit_init() is used by both x86 and arm64, and
the code is the same, move it to common place to simplify
the code, and mark it as __weak because the different
implimentation for ia64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 31 -------------------------------
arch/x86/mm/srat.c | 27 ---------------------------
drivers/acpi/numa.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 30 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533..15fb935 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -64,37 +64,6 @@ void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
cpu_to_node_map[cpu] = nid;
}
-/*
- * Callback for SLIT parsing.
- * It will get the distance information presented by SLIT
- * and init the distance matrix of numa nodes
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- pr_debug("SLIT: Distance[%d][%d] = %d\n",
- from_node, to_node,
- slit->entry[
- slit->locality_count * i + j]);
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
{
unsigned long madt_end, entry;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 9fa1746..92a640a 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -42,33 +42,6 @@ static __init inline int srat_disabled(void)
return acpi_numa < 0;
}
-/*
- * Callback for SLIT parsing. pxm_to_node() returns NUMA_NO_NODE for
- * I/O localities since SRAT does not list them. I/O localities are
- * not supported@this point.
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4728525..b33915e 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -209,6 +209,36 @@ static int __init slit_valid(struct acpi_table_slit *slit)
return 1;
}
+/*
+ * Callback for SLIT parsing. It will get the distance information
+ * presented by SLIT and init the distance matrix of numa nodes
+ */
+void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 07/12] acpi, numa: move acpi_numa_slit_init() to common place
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa_slit_init() is used by both x86 and arm64, and
the code is the same, move it to common place to simplify
the code, and mark it as __weak because the different
implimentation for ia64.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 31 -------------------------------
arch/x86/mm/srat.c | 27 ---------------------------
drivers/acpi/numa.c | 30 ++++++++++++++++++++++++++++++
3 files changed, 30 insertions(+), 58 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index f7f7533..15fb935 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -64,37 +64,6 @@ void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
cpu_to_node_map[cpu] = nid;
}
-/*
- * Callback for SLIT parsing.
- * It will get the distance information presented by SLIT
- * and init the distance matrix of numa nodes
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- pr_debug("SLIT: Distance[%d][%d] = %d\n",
- from_node, to_node,
- slit->entry[
- slit->locality_count * i + j]);
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
static int __init get_mpidr_in_madt(int acpi_id, u64 *mpidr)
{
unsigned long madt_end, entry;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 9fa1746..92a640a 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -42,33 +42,6 @@ static __init inline int srat_disabled(void)
return acpi_numa < 0;
}
-/*
- * Callback for SLIT parsing. pxm_to_node() returns NUMA_NO_NODE for
- * I/O localities since SRAT does not list them. I/O localities are
- * not supported at this point.
- */
-void __init acpi_numa_slit_init(struct acpi_table_slit *slit)
-{
- int i, j;
-
- for (i = 0; i < slit->locality_count; i++) {
- const int from_node = pxm_to_node(i);
-
- if (from_node == NUMA_NO_NODE)
- continue;
-
- for (j = 0; j < slit->locality_count; j++) {
- const int to_node = pxm_to_node(j);
-
- if (to_node == NUMA_NO_NODE)
- continue;
-
- numa_set_distance(from_node, to_node,
- slit->entry[slit->locality_count * i + j]);
- }
- }
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 4728525..b33915e 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -209,6 +209,36 @@ static int __init slit_valid(struct acpi_table_slit *slit)
return 1;
}
+/*
+ * Callback for SLIT parsing. It will get the distance information
+ * presented by SLIT and init the distance matrix of numa nodes
+ */
+void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
+{
+ int i, j;
+
+ for (i = 0; i < slit->locality_count; i++) {
+ const int from_node = pxm_to_node(i);
+
+ if (from_node == NUMA_NO_NODE)
+ continue;
+
+ for (j = 0; j < slit->locality_count; j++) {
+ const int to_node = pxm_to_node(j);
+
+ if (to_node == NUMA_NO_NODE)
+ continue;
+
+ numa_set_distance(from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+
+ pr_debug("SLIT: Distance[%d][%d] = %d\n",
+ from_node, to_node,
+ slit->entry[slit->locality_count * i + j]);
+ }
+ }
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Rework numa_add_memblk() to update the parameter "u64 size"
to "u64 end", this will make it consistent with x86 and
can simplify the code later.
Updates for arch/arm64/mm/numa.c should squash to core NUMA
patches from Ganapat.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 2 +-
arch/arm64/kernel/of_numa.c | 2 +-
arch/arm64/mm/numa.c | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 15fb935..3bcf058 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -184,7 +184,7 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
node, pxm,
(unsigned long long) start, (unsigned long long) end - 1);
- if (numa_add_memblk(node, start, (end - start)) < 0) {
+ if (numa_add_memblk(node, start, end) < 0) {
bad_srat();
return -EINVAL;
}
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
index 2f9e34b..aa6f3a3 100644
--- a/arch/arm64/kernel/of_numa.c
+++ b/arch/arm64/kernel/of_numa.c
@@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
pr_debug("NUMA-DT: base = %llx , node = %u\n",
base, nid);
- if (numa_add_memblk(nid, base, size) < 0)
+ if (numa_add_memblk(nid, base, base + size) < 0)
return -EINVAL;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e974995..2b04b8a 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
* numa_add_memblk - Set node id to memblk
* @nid: NUMA node ID of the new memblk
* @start: Start address of the new memblk
- * @size: Size of the new memblk
+ * @end: End address of the new memblk
*
* RETURNS:
* 0 on success, -errno on failure.
*/
-int __init numa_add_memblk(int nid, u64 start, u64 size)
+int __init numa_add_memblk(int nid, u64 start, u64 end)
{
int ret;
- ret = memblock_set_node(start, size, &memblock.memory, nid);
+ ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
node_set(nid, numa_nodes_parsed);
pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
EXPORT_SYMBOL(numa_add_memblk);
@@ -366,7 +366,7 @@ static int __init dummy_numa_init(void)
0LLU, PFN_PHYS(max_pfn) - 1);
for_each_memblock(memory, mblk) {
- ret = numa_add_memblk(0, mblk->base, mblk->size);
+ ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
if (unlikely(ret < 0))
return ret;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Rework numa_add_memblk() to update the parameter "u64 size"
to "u64 end", this will make it consistent with x86 and
can simplify the code later.
Updates for arch/arm64/mm/numa.c should squash to core NUMA
patches from Ganapat.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 2 +-
arch/arm64/kernel/of_numa.c | 2 +-
arch/arm64/mm/numa.c | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 15fb935..3bcf058 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -184,7 +184,7 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
node, pxm,
(unsigned long long) start, (unsigned long long) end - 1);
- if (numa_add_memblk(node, start, (end - start)) < 0) {
+ if (numa_add_memblk(node, start, end) < 0) {
bad_srat();
return -EINVAL;
}
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
index 2f9e34b..aa6f3a3 100644
--- a/arch/arm64/kernel/of_numa.c
+++ b/arch/arm64/kernel/of_numa.c
@@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
pr_debug("NUMA-DT: base = %llx , node = %u\n",
base, nid);
- if (numa_add_memblk(nid, base, size) < 0)
+ if (numa_add_memblk(nid, base, base + size) < 0)
return -EINVAL;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e974995..2b04b8a 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
* numa_add_memblk - Set node id to memblk
* @nid: NUMA node ID of the new memblk
* @start: Start address of the new memblk
- * @size: Size of the new memblk
+ * @end: End address of the new memblk
*
* RETURNS:
* 0 on success, -errno on failure.
*/
-int __init numa_add_memblk(int nid, u64 start, u64 size)
+int __init numa_add_memblk(int nid, u64 start, u64 end)
{
int ret;
- ret = memblock_set_node(start, size, &memblock.memory, nid);
+ ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
node_set(nid, numa_nodes_parsed);
pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
EXPORT_SYMBOL(numa_add_memblk);
@@ -366,7 +366,7 @@ static int __init dummy_numa_init(void)
0LLU, PFN_PHYS(max_pfn) - 1);
for_each_memblock(memory, mblk) {
- ret = numa_add_memblk(0, mblk->base, mblk->size);
+ ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
if (unlikely(ret < 0))
return ret;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Rework numa_add_memblk() to update the parameter "u64 size"
to "u64 end", this will make it consistent with x86 and
can simplify the code later.
Updates for arch/arm64/mm/numa.c should squash to core NUMA
patches from Ganapat.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 2 +-
arch/arm64/kernel/of_numa.c | 2 +-
arch/arm64/mm/numa.c | 12 ++++++------
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 15fb935..3bcf058 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -184,7 +184,7 @@ int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
node, pxm,
(unsigned long long) start, (unsigned long long) end - 1);
- if (numa_add_memblk(node, start, (end - start)) < 0) {
+ if (numa_add_memblk(node, start, end) < 0) {
bad_srat();
return -EINVAL;
}
diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
index 2f9e34b..aa6f3a3 100644
--- a/arch/arm64/kernel/of_numa.c
+++ b/arch/arm64/kernel/of_numa.c
@@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
pr_debug("NUMA-DT: base = %llx , node = %u\n",
base, nid);
- if (numa_add_memblk(nid, base, size) < 0)
+ if (numa_add_memblk(nid, base, base + size) < 0)
return -EINVAL;
}
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e974995..2b04b8a 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
* numa_add_memblk - Set node id to memblk
* @nid: NUMA node ID of the new memblk
* @start: Start address of the new memblk
- * @size: Size of the new memblk
+ * @end: End address of the new memblk
*
* RETURNS:
* 0 on success, -errno on failure.
*/
-int __init numa_add_memblk(int nid, u64 start, u64 size)
+int __init numa_add_memblk(int nid, u64 start, u64 end)
{
int ret;
- ret = memblock_set_node(start, size, &memblock.memory, nid);
+ ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
if (ret < 0) {
pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
node_set(nid, numa_nodes_parsed);
pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
- start, (start + size - 1), nid);
+ start, (end - 1), nid);
return ret;
}
EXPORT_SYMBOL(numa_add_memblk);
@@ -366,7 +366,7 @@ static int __init dummy_numa_init(void)
0LLU, PFN_PHYS(max_pfn) - 1);
for_each_memblock(memory, mblk) {
- ret = numa_add_memblk(0, mblk->base, mblk->size);
+ ret = numa_add_memblk(0, mblk->base, mblk->base + mblk->size);
if (unlikely(ret < 0))
return ret;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-25 9:34 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 9:34 UTC (permalink / raw)
To: Hanjun Guo
Cc: Mark Rutland, Lorenzo Pieralisi, Steve Capper, Rafael J. Wysocki,
Will Deacon, linux-kernel, linux-acpi, Shannon Zhao,
Catalin Marinas, Ganapatrao Kulkarni, linux-arm-kernel,
Hanjun Guo
On 23.01.16 17:39:23, Hanjun Guo wrote:
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
The overall function usage looks more like as it should use size
instead of end. Even in the x86 implementation end is calculated from
base + size. So better change x86 code to use size instead.
Though this might involve to change the interface for
numa_add_memblk_to() for unifcation too.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-25 9:34 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 9:34 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:23, Hanjun Guo wrote:
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
The overall function usage looks more like as it should use size
instead of end. Even in the x86 implementation end is calculated from
base + size. So better change x86 code to use size instead.
Though this might involve to change the interface for
numa_add_memblk_to() for unifcation too.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-25 9:34 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 9:34 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:23, Hanjun Guo wrote:
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
The overall function usage looks more like as it should use size
instead of end. Even in the x86 implementation end is calculated from
base + size. So better change x86 code to use size instead.
Though this might involve to change the interface for
numa_add_memblk_to() for unifcation too.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
2016-01-25 9:34 ` Robert Richter
(?)
@ 2016-01-27 6:20 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:20 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/25 17:34, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>> pr_debug("NUMA-DT: base = %llx , node = %u\n",
>> base, nid);
>>
>> - if (numa_add_memblk(nid, base, size) < 0)
>> + if (numa_add_memblk(nid, base, base + size) < 0)
> The overall function usage looks more like as it should use size
> instead of end. Even in the x86 implementation end is calculated from
> base + size. So better change x86 code to use size instead.
>
> Though this might involve to change the interface for
> numa_add_memblk_to() for unifcation too.
>
This should be a minor one, I'm fine with both directions, I will
stay for a few days to get more review comments, if no objections,
I will update.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-27 6:20 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:20 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/25 17:34, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>> pr_debug("NUMA-DT: base = %llx , node = %u\n",
>> base, nid);
>>
>> - if (numa_add_memblk(nid, base, size) < 0)
>> + if (numa_add_memblk(nid, base, base + size) < 0)
> The overall function usage looks more like as it should use size
> instead of end. Even in the x86 implementation end is calculated from
> base + size. So better change x86 code to use size instead.
>
> Though this might involve to change the interface for
> numa_add_memblk_to() for unifcation too.
>
This should be a minor one, I'm fine with both directions, I will
stay for a few days to get more review comments, if no objections,
I will update.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-01-27 6:20 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:20 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/25 17:34, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>> pr_debug("NUMA-DT: base = %llx , node = %u\n",
>> base, nid);
>>
>> - if (numa_add_memblk(nid, base, size) < 0)
>> + if (numa_add_memblk(nid, base, base + size) < 0)
> The overall function usage looks more like as it should use size
> instead of end. Even in the x86 implementation end is calculated from
> base + size. So better change x86 code to use size instead.
>
> Though this might involve to change the interface for
> numa_add_memblk_to() for unifcation too.
>
This should be a minor one, I'm fine with both directions, I will
stay for a few days to get more review comments, if no objections,
I will update.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-03-09 12:27 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-03-09 12:27 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:23, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
>
> Updates for arch/arm64/mm/numa.c should squash to core NUMA
> patches from Ganapat.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 2 +-
> arch/arm64/kernel/of_numa.c | 2 +-
> arch/arm64/mm/numa.c | 12 ++++++------
> 3 files changed, 8 insertions(+), 8 deletions(-)
> diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
> index 2f9e34b..aa6f3a3 100644
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
> return -EINVAL;
> }
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index e974995..2b04b8a 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
> * numa_add_memblk - Set node id to memblk
> * @nid: NUMA node ID of the new memblk
> * @start: Start address of the new memblk
> - * @size: Size of the new memblk
> + * @end: End address of the new memblk
Apart from my earlier comment, this is not exactly correct and may
cause confussion. The implementation here defines:
size == end - start
which is different to struct resource, where:
resource_size(res) == res->end - res->start + 1
Thus, @end here is the first address outside of memblk.
This is one more argument for keeping @size here.
-Robert
> *
> * RETURNS:
> * 0 on success, -errno on failure.
> */
> -int __init numa_add_memblk(int nid, u64 start, u64 size)
> +int __init numa_add_memblk(int nid, u64 start, u64 end)
> {
> int ret;
>
> - ret = memblock_set_node(start, size, &memblock.memory, nid);
> + ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
> if (ret < 0) {
> pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
>
> node_set(nid, numa_nodes_parsed);
> pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-03-09 12:27 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-03-09 12:27 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:23, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
>
> Updates for arch/arm64/mm/numa.c should squash to core NUMA
> patches from Ganapat.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 2 +-
> arch/arm64/kernel/of_numa.c | 2 +-
> arch/arm64/mm/numa.c | 12 ++++++------
> 3 files changed, 8 insertions(+), 8 deletions(-)
> diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
> index 2f9e34b..aa6f3a3 100644
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
> return -EINVAL;
> }
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index e974995..2b04b8a 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
> * numa_add_memblk - Set node id to memblk
> * @nid: NUMA node ID of the new memblk
> * @start: Start address of the new memblk
> - * @size: Size of the new memblk
> + * @end: End address of the new memblk
Apart from my earlier comment, this is not exactly correct and may
cause confussion. The implementation here defines:
size == end - start
which is different to struct resource, where:
resource_size(res) == res->end - res->start + 1
Thus, @end here is the first address outside of memblk.
This is one more argument for keeping @size here.
-Robert
> *
> * RETURNS:
> * 0 on success, -errno on failure.
> */
> -int __init numa_add_memblk(int nid, u64 start, u64 size)
> +int __init numa_add_memblk(int nid, u64 start, u64 end)
> {
> int ret;
>
> - ret = memblock_set_node(start, size, &memblock.memory, nid);
> + ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
> if (ret < 0) {
> pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
>
> node_set(nid, numa_nodes_parsed);
> pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-03-09 12:27 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-03-09 12:27 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:23, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> Rework numa_add_memblk() to update the parameter "u64 size"
> to "u64 end", this will make it consistent with x86 and
> can simplify the code later.
>
> Updates for arch/arm64/mm/numa.c should squash to core NUMA
> patches from Ganapat.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 2 +-
> arch/arm64/kernel/of_numa.c | 2 +-
> arch/arm64/mm/numa.c | 12 ++++++------
> 3 files changed, 8 insertions(+), 8 deletions(-)
> diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
> index 2f9e34b..aa6f3a3 100644
> --- a/arch/arm64/kernel/of_numa.c
> +++ b/arch/arm64/kernel/of_numa.c
> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
> pr_debug("NUMA-DT: base = %llx , node = %u\n",
> base, nid);
>
> - if (numa_add_memblk(nid, base, size) < 0)
> + if (numa_add_memblk(nid, base, base + size) < 0)
> return -EINVAL;
> }
>
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index e974995..2b04b8a 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
> * numa_add_memblk - Set node id to memblk
> * @nid: NUMA node ID of the new memblk
> * @start: Start address of the new memblk
> - * @size: Size of the new memblk
> + * @end: End address of the new memblk
Apart from my earlier comment, this is not exactly correct and may
cause confussion. The implementation here defines:
size == end - start
which is different to struct resource, where:
resource_size(res) == res->end - res->start + 1
Thus, @end here is the first address outside of memblk.
This is one more argument for keeping @size here.
-Robert
> *
> * RETURNS:
> * 0 on success, -errno on failure.
> */
> -int __init numa_add_memblk(int nid, u64 start, u64 size)
> +int __init numa_add_memblk(int nid, u64 start, u64 end)
> {
> int ret;
>
> - ret = memblock_set_node(start, size, &memblock.memory, nid);
> + ret = memblock_set_node(start, (end - start), &memblock.memory, nid);
> if (ret < 0) {
> pr_err("NUMA: memblock [0x%llx - 0x%llx] failed to add on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
>
> node_set(nid, numa_nodes_parsed);
> pr_info("NUMA: Adding memblock [0x%llx - 0x%llx] on node %d\n",
> - start, (start + size - 1), nid);
> + start, (end - 1), nid);
> return ret;
> }
^ permalink raw reply [flat|nested] 100+ messages in thread* Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
2016-03-09 12:27 ` Robert Richter
@ 2016-03-10 10:10 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-03-10 10:10 UTC (permalink / raw)
To: Robert Richter, Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland
Hi Robert,
On 03/09/2016 08:27 PM, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>>
>> Updates for arch/arm64/mm/numa.c should squash to core NUMA
>> patches from Ganapat.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/kernel/acpi_numa.c | 2 +-
>> arch/arm64/kernel/of_numa.c | 2 +-
>> arch/arm64/mm/numa.c | 12 ++++++------
>> 3 files changed, 8 insertions(+), 8 deletions(-)
>
>> diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
>> index 2f9e34b..aa6f3a3 100644
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>> pr_debug("NUMA-DT: base = %llx , node = %u\n",
>> base, nid);
>>
>> - if (numa_add_memblk(nid, base, size) < 0)
>> + if (numa_add_memblk(nid, base, base + size) < 0)
>> return -EINVAL;
>> }
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index e974995..2b04b8a 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
>> * numa_add_memblk - Set node id to memblk
>> * @nid: NUMA node ID of the new memblk
>> * @start: Start address of the new memblk
>> - * @size: Size of the new memblk
>> + * @end: End address of the new memblk
>
> Apart from my earlier comment, this is not exactly correct and may
> cause confussion. The implementation here defines:
>
> size == end - start
>
> which is different to struct resource, where:
>
> resource_size(res) == res->end - res->start + 1
>
> Thus, @end here is the first address outside of memblk.
>
> This is one more argument for keeping @size here.
I agree :)
I'm working on the new version and met the problem of no
definition for numa_add_memblk() and numa_set_distance()
on IA64, numa_set_distance() seems to easy to add one for
IA64, but numa_add_memblk() is not, this will the blocker
for moving functions to common place, what's your opinion
here?
Also I'm thinking to move all the code in arch/arm64/kernel/acpi_numa.c
to the arch/arm64/kernel/acpi.c to make the ACPI code in ARM64
self-contained, what do you think?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread* [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()
@ 2016-03-10 10:10 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-03-10 10:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Robert,
On 03/09/2016 08:27 PM, Robert Richter wrote:
> On 23.01.16 17:39:23, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> Rework numa_add_memblk() to update the parameter "u64 size"
>> to "u64 end", this will make it consistent with x86 and
>> can simplify the code later.
>>
>> Updates for arch/arm64/mm/numa.c should squash to core NUMA
>> patches from Ganapat.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/kernel/acpi_numa.c | 2 +-
>> arch/arm64/kernel/of_numa.c | 2 +-
>> arch/arm64/mm/numa.c | 12 ++++++------
>> 3 files changed, 8 insertions(+), 8 deletions(-)
>
>> diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
>> index 2f9e34b..aa6f3a3 100644
>> --- a/arch/arm64/kernel/of_numa.c
>> +++ b/arch/arm64/kernel/of_numa.c
>> @@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned long node)
>> pr_debug("NUMA-DT: base = %llx , node = %u\n",
>> base, nid);
>>
>> - if (numa_add_memblk(nid, base, size) < 0)
>> + if (numa_add_memblk(nid, base, base + size) < 0)
>> return -EINVAL;
>> }
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index e974995..2b04b8a 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
>> * numa_add_memblk - Set node id to memblk
>> * @nid: NUMA node ID of the new memblk
>> * @start: Start address of the new memblk
>> - * @size: Size of the new memblk
>> + * @end: End address of the new memblk
>
> Apart from my earlier comment, this is not exactly correct and may
> cause confussion. The implementation here defines:
>
> size == end - start
>
> which is different to struct resource, where:
>
> resource_size(res) == res->end - res->start + 1
>
> Thus, @end here is the first address outside of memblk.
>
> This is one more argument for keeping @size here.
I agree :)
I'm working on the new version and met the problem of no
definition for numa_add_memblk() and numa_set_distance()
on IA64, numa_set_distance() seems to easy to add one for
IA64, but numa_add_memblk() is not, this will the blocker
for moving functions to common place, what's your opinion
here?
Also I'm thinking to move all the code in arch/arm64/kernel/acpi_numa.c
to the arch/arm64/kernel/acpi.c to make the ACPI code in ARM64
self-contained, what do you think?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 09/12] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Cleanup acpi_numa_processor_affinity_init() and prepare
move it to common palce then it can be reused by other
arch, this should no functional change.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/x86/mm/srat.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 92a640a..304cdf2 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -26,11 +26,6 @@
int acpi_numa __initdata;
-static __init int setup_node(int pxm)
-{
- return acpi_map_pxm_to_node(pxm);
-}
-
static __init void bad_srat(void)
{
printk(KERN_ERR "SRAT: SRAT not used.\n");
@@ -64,7 +59,7 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
pxm, apic_id);
return;
}
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -100,7 +95,7 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm = pa->proximity_domain_lo;
if (acpi_srat_revision >= 2)
pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -124,12 +119,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-#ifdef CONFIG_MEMORY_HOTPLUG
-static inline int save_add_info(void) {return 1;}
-#else
-static inline int save_add_info(void) {return 0;}
-#endif
-
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
int __init
acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
@@ -145,7 +134,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
goto out_err;
hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !save_add_info())
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
goto out_err;
start = ma->base_address;
@@ -154,7 +143,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (acpi_srat_revision <= 1)
pxm &= 0xff;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains.\n");
goto out_err_bad_srat;
@@ -180,7 +169,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
out_err_bad_srat:
bad_srat();
out_err:
- return -1;
+ return -EINVAL;
}
int __init x86_acpi_numa_init(void)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 09/12] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
Cleanup acpi_numa_processor_affinity_init() and prepare
move it to common palce then it can be reused by other
arch, this should no functional change.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/x86/mm/srat.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 92a640a..304cdf2 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -26,11 +26,6 @@
int acpi_numa __initdata;
-static __init int setup_node(int pxm)
-{
- return acpi_map_pxm_to_node(pxm);
-}
-
static __init void bad_srat(void)
{
printk(KERN_ERR "SRAT: SRAT not used.\n");
@@ -64,7 +59,7 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
pxm, apic_id);
return;
}
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -100,7 +95,7 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm = pa->proximity_domain_lo;
if (acpi_srat_revision >= 2)
pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -124,12 +119,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-#ifdef CONFIG_MEMORY_HOTPLUG
-static inline int save_add_info(void) {return 1;}
-#else
-static inline int save_add_info(void) {return 0;}
-#endif
-
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
int __init
acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
@@ -145,7 +134,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
goto out_err;
hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !save_add_info())
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
goto out_err;
start = ma->base_address;
@@ -154,7 +143,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (acpi_srat_revision <= 1)
pxm &= 0xff;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains.\n");
goto out_err_bad_srat;
@@ -180,7 +169,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
out_err_bad_srat:
bad_srat();
out_err:
- return -1;
+ return -EINVAL;
}
int __init x86_acpi_numa_init(void)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 09/12] x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
Cleanup acpi_numa_processor_affinity_init() and prepare
move it to common palce then it can be reused by other
arch, this should no functional change.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/x86/mm/srat.c | 21 +++++----------------
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 92a640a..304cdf2 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -26,11 +26,6 @@
int acpi_numa __initdata;
-static __init int setup_node(int pxm)
-{
- return acpi_map_pxm_to_node(pxm);
-}
-
static __init void bad_srat(void)
{
printk(KERN_ERR "SRAT: SRAT not used.\n");
@@ -64,7 +59,7 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
pxm, apic_id);
return;
}
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -100,7 +95,7 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm = pa->proximity_domain_lo;
if (acpi_srat_revision >= 2)
pxm |= *((unsigned int*)pa->proximity_domain_hi) << 8;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains %x\n", pxm);
bad_srat();
@@ -124,12 +119,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-#ifdef CONFIG_MEMORY_HOTPLUG
-static inline int save_add_info(void) {return 1;}
-#else
-static inline int save_add_info(void) {return 0;}
-#endif
-
/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
int __init
acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
@@ -145,7 +134,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
goto out_err;
hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !save_add_info())
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
goto out_err;
start = ma->base_address;
@@ -154,7 +143,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
if (acpi_srat_revision <= 1)
pxm &= 0xff;
- node = setup_node(pxm);
+ node = acpi_map_pxm_to_node(pxm);
if (node < 0) {
printk(KERN_ERR "SRAT: Too many proximity domains.\n");
goto out_err_bad_srat;
@@ -180,7 +169,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
out_err_bad_srat:
bad_srat();
out_err:
- return -1;
+ return -EINVAL;
}
int __init x86_acpi_numa_init(void)
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 10/12] acpi, numa: move bad_srat() and srat_disabled() to common place
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
bad_srat() and srat_disabled() are shared by arm64 and x86,
move it to common place to reduce duplication.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 12 ------------
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 13 -------------
drivers/acpi/numa.c | 1 +
include/acpi/acpi_numa.h | 12 ++++++++++++
6 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 3bcf058..fb1556f 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -28,7 +28,6 @@
#include <acpi/processor.h>
#include <asm/numa.h>
-int acpi_numa __initdata;
static int cpus_in_srat;
struct __node_cpu_hwid {
@@ -39,17 +38,6 @@ struct __node_cpu_hwid {
static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
-static __init void bad_srat(void)
-{
- pr_err("SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
{
int nid = 0, i;
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 94c18eb..65f1e95 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -145,7 +145,6 @@ static inline void disable_acpi(void) { }
#define ARCH_HAS_POWER_INIT 1
#ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
extern int x86_acpi_numa_init(void);
#endif /* CONFIG_ACPI_NUMA */
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..fd59371 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -1,4 +1,5 @@
/* Common code for 32 and 64-bit NUMA */
+#include <linux/acpi.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/string.h>
@@ -15,7 +16,6 @@
#include <asm/e820.h>
#include <asm/proto.h>
#include <asm/dma.h>
-#include <asm/acpi.h>
#include <asm/amd_nb.h>
#include "numa_internal.h"
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 304cdf2..7078b3f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -24,19 +24,6 @@
#include <asm/apic.h>
#include <asm/uv/uv.h>
-int acpi_numa __initdata;
-
-static __init void bad_srat(void)
-{
- printk(KERN_ERR "SRAT: SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index b33915e..05e3795 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -40,6 +40,7 @@ static int node_to_pxm_map[MAX_NUMNODES]
= { [0 ... MAX_NUMNODES - 1] = PXM_INVAL };
unsigned char acpi_srat_revision __initdata;
+int acpi_numa __initdata;
int pxm_to_node(int pxm)
{
diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
index 94a37cd..28f06a6 100644
--- a/include/acpi/acpi_numa.h
+++ b/include/acpi/acpi_numa.h
@@ -15,6 +15,18 @@ extern int pxm_to_node(int);
extern int node_to_pxm(int);
extern int acpi_map_pxm_to_node(int);
extern unsigned char acpi_srat_revision;
+extern int acpi_numa __initdata;
+
+static inline void bad_srat(void)
+{
+ pr_err("SRAT: SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
#endif /* CONFIG_ACPI_NUMA */
#endif /* __ACP_NUMA_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 10/12] acpi, numa: move bad_srat() and srat_disabled() to common place
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
bad_srat() and srat_disabled() are shared by arm64 and x86,
move it to common place to reduce duplication.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 12 ------------
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 13 -------------
drivers/acpi/numa.c | 1 +
include/acpi/acpi_numa.h | 12 ++++++++++++
6 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 3bcf058..fb1556f 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -28,7 +28,6 @@
#include <acpi/processor.h>
#include <asm/numa.h>
-int acpi_numa __initdata;
static int cpus_in_srat;
struct __node_cpu_hwid {
@@ -39,17 +38,6 @@ struct __node_cpu_hwid {
static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
-static __init void bad_srat(void)
-{
- pr_err("SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
{
int nid = 0, i;
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 94c18eb..65f1e95 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -145,7 +145,6 @@ static inline void disable_acpi(void) { }
#define ARCH_HAS_POWER_INIT 1
#ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
extern int x86_acpi_numa_init(void);
#endif /* CONFIG_ACPI_NUMA */
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..fd59371 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -1,4 +1,5 @@
/* Common code for 32 and 64-bit NUMA */
+#include <linux/acpi.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/string.h>
@@ -15,7 +16,6 @@
#include <asm/e820.h>
#include <asm/proto.h>
#include <asm/dma.h>
-#include <asm/acpi.h>
#include <asm/amd_nb.h>
#include "numa_internal.h"
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 304cdf2..7078b3f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -24,19 +24,6 @@
#include <asm/apic.h>
#include <asm/uv/uv.h>
-int acpi_numa __initdata;
-
-static __init void bad_srat(void)
-{
- printk(KERN_ERR "SRAT: SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index b33915e..05e3795 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -40,6 +40,7 @@ static int node_to_pxm_map[MAX_NUMNODES]
= { [0 ... MAX_NUMNODES - 1] = PXM_INVAL };
unsigned char acpi_srat_revision __initdata;
+int acpi_numa __initdata;
int pxm_to_node(int pxm)
{
diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
index 94a37cd..28f06a6 100644
--- a/include/acpi/acpi_numa.h
+++ b/include/acpi/acpi_numa.h
@@ -15,6 +15,18 @@ extern int pxm_to_node(int);
extern int node_to_pxm(int);
extern int acpi_map_pxm_to_node(int);
extern unsigned char acpi_srat_revision;
+extern int acpi_numa __initdata;
+
+static inline void bad_srat(void)
+{
+ pr_err("SRAT: SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
#endif /* CONFIG_ACPI_NUMA */
#endif /* __ACP_NUMA_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 10/12] acpi, numa: move bad_srat() and srat_disabled() to common place
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
bad_srat() and srat_disabled() are shared by arm64 and x86,
move it to common place to reduce duplication.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 12 ------------
arch/x86/include/asm/acpi.h | 1 -
arch/x86/mm/numa.c | 2 +-
arch/x86/mm/srat.c | 13 -------------
drivers/acpi/numa.c | 1 +
include/acpi/acpi_numa.h | 12 ++++++++++++
6 files changed, 14 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 3bcf058..fb1556f 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -28,7 +28,6 @@
#include <acpi/processor.h>
#include <asm/numa.h>
-int acpi_numa __initdata;
static int cpus_in_srat;
struct __node_cpu_hwid {
@@ -39,17 +38,6 @@ struct __node_cpu_hwid {
static struct __node_cpu_hwid early_node_cpu_hwid[NR_CPUS] = {
[0 ... NR_CPUS - 1] = {NUMA_NO_NODE, PHYS_CPUID_INVALID} };
-static __init void bad_srat(void)
-{
- pr_err("SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
void __init acpi_numa_set_node_info(unsigned int cpu, u64 hwid)
{
int nid = 0, i;
diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 94c18eb..65f1e95 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -145,7 +145,6 @@ static inline void disable_acpi(void) { }
#define ARCH_HAS_POWER_INIT 1
#ifdef CONFIG_ACPI_NUMA
-extern int acpi_numa;
extern int x86_acpi_numa_init(void);
#endif /* CONFIG_ACPI_NUMA */
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..fd59371 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -1,4 +1,5 @@
/* Common code for 32 and 64-bit NUMA */
+#include <linux/acpi.h>
#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/string.h>
@@ -15,7 +16,6 @@
#include <asm/e820.h>
#include <asm/proto.h>
#include <asm/dma.h>
-#include <asm/acpi.h>
#include <asm/amd_nb.h>
#include "numa_internal.h"
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 304cdf2..7078b3f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -24,19 +24,6 @@
#include <asm/apic.h>
#include <asm/uv/uv.h>
-int acpi_numa __initdata;
-
-static __init void bad_srat(void)
-{
- printk(KERN_ERR "SRAT: SRAT not used.\n");
- acpi_numa = -1;
-}
-
-static __init inline int srat_disabled(void)
-{
- return acpi_numa < 0;
-}
-
/* Callback for Proximity Domain -> x2APIC mapping */
void __init
acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index b33915e..05e3795 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -40,6 +40,7 @@ static int node_to_pxm_map[MAX_NUMNODES]
= { [0 ... MAX_NUMNODES - 1] = PXM_INVAL };
unsigned char acpi_srat_revision __initdata;
+int acpi_numa __initdata;
int pxm_to_node(int pxm)
{
diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
index 94a37cd..28f06a6 100644
--- a/include/acpi/acpi_numa.h
+++ b/include/acpi/acpi_numa.h
@@ -15,6 +15,18 @@ extern int pxm_to_node(int);
extern int node_to_pxm(int);
extern int acpi_map_pxm_to_node(int);
extern unsigned char acpi_srat_revision;
+extern int acpi_numa __initdata;
+
+static inline void bad_srat(void)
+{
+ pr_err("SRAT: SRAT not used.\n");
+ acpi_numa = -1;
+}
+
+static inline int srat_disabled(void)
+{
+ return acpi_numa < 0;
+}
#endif /* CONFIG_ACPI_NUMA */
#endif /* __ACP_NUMA_H */
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 11/12] acpi, numa: remove unneeded acpi_numa=1
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa is default to 0, it's set to -1 when disable acpi numa or
when a bad SRAT is parsed, and it's only consumed in srat_disabled()
(compare it with 0) to continue parse the SRAT or not, so we don't
need to set acpi_numa to 1 when we get a valid SRAT entry.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 1 -
arch/x86/mm/srat.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index fb1556f..03ac1b9 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -132,7 +132,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
early_node_cpu_hwid[cpus_in_srat].node_id = node;
early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
cpus_in_srat++;
pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
pxm, mpidr, node, cpus_in_srat);
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 7078b3f..af1dc14 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -59,7 +59,6 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
}
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
pxm, apic_id, node);
}
@@ -101,7 +100,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
pxm, apic_id, node);
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 11/12] acpi, numa: remove unneeded acpi_numa=1
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa is default to 0, it's set to -1 when disable acpi numa or
when a bad SRAT is parsed, and it's only consumed in srat_disabled()
(compare it with 0) to continue parse the SRAT or not, so we don't
need to set acpi_numa to 1 when we get a valid SRAT entry.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 1 -
arch/x86/mm/srat.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index fb1556f..03ac1b9 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -132,7 +132,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
early_node_cpu_hwid[cpus_in_srat].node_id = node;
early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
cpus_in_srat++;
pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
pxm, mpidr, node, cpus_in_srat);
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 7078b3f..af1dc14 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -59,7 +59,6 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
}
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
pxm, apic_id, node);
}
@@ -101,7 +100,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
pxm, apic_id, node);
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 11/12] acpi, numa: remove unneeded acpi_numa=1
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
acpi_numa is default to 0, it's set to -1 when disable acpi numa or
when a bad SRAT is parsed, and it's only consumed in srat_disabled()
(compare it with 0) to continue parse the SRAT or not, so we don't
need to set acpi_numa to 1 when we get a valid SRAT entry.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 1 -
arch/x86/mm/srat.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index fb1556f..03ac1b9 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -132,7 +132,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
early_node_cpu_hwid[cpus_in_srat].node_id = node;
early_node_cpu_hwid[cpus_in_srat].cpu_hwid = mpidr;
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
cpus_in_srat++;
pr_info("SRAT: PXM %d -> MPIDR 0x%Lx -> Node %d cpu %d\n",
pxm, mpidr, node, cpus_in_srat);
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index 7078b3f..af1dc14 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -59,7 +59,6 @@ acpi_numa_x2apic_affinity_init(struct acpi_srat_x2apic_cpu_affinity *pa)
}
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u\n",
pxm, apic_id, node);
}
@@ -101,7 +100,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
set_apicid_to_node(apic_id, node);
node_set(node, numa_nodes_parsed);
- acpi_numa = 1;
printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u\n",
pxm, apic_id, node);
}
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-23 9:39 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
After the cleanup for acpi_numa_memory_affinity_init(),
it can be used for architetures both x86 and arm64, since
CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
worry about that.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
arch/x86/mm/srat.c | 54 ----------------------------------------
drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 96 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 03ac1b9..5c01b06 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -137,48 +137,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
pxm, mpidr, node, cpus_in_srat);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- int node, pxm;
-
- if (srat_disabled())
- return -EINVAL;
-
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
- bad_srat();
- return -EINVAL;
- }
-
- /* Ignore disabled entries */
- if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
- return -EINVAL;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
-
- node = acpi_map_pxm_to_node(pxm);
-
- if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
- pr_err("SRAT: Too many proximity domains.\n");
- bad_srat();
- return -EINVAL;
- }
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1);
-
- if (numa_add_memblk(node, start, end) < 0) {
- bad_srat();
- return -EINVAL;
- }
-
- return 0;
-}
-
int __init arm64_acpi_numa_init(void)
{
int ret;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index af1dc14..cbd792f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/topology.h>
#include <linux/bootmem.h>
-#include <linux/memblock.h>
#include <linux/mm.h>
#include <asm/proto.h>
#include <asm/numa.h>
@@ -104,59 +103,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init
-acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- u32 hotpluggable;
- int node, pxm;
-
- if (srat_disabled())
- goto out_err;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
- goto out_err_bad_srat;
- if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
- goto out_err;
- hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
- goto out_err;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
- if (acpi_srat_revision <= 1)
- pxm &= 0xff;
-
- node = acpi_map_pxm_to_node(pxm);
- if (node < 0) {
- printk(KERN_ERR "SRAT: Too many proximity domains.\n");
- goto out_err_bad_srat;
- }
-
- if (numa_add_memblk(node, start, end) < 0)
- goto out_err_bad_srat;
-
- node_set(node, numa_nodes_parsed);
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1,
- hotpluggable ? " hotplug" : "",
- ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
-
- /* Mark hotplug range in memblock. */
- if (hotpluggable && memblock_mark_hotplug(start, ma->length))
- pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
- (unsigned long long)start, (unsigned long long)end - 1);
-
- return 0;
-out_err_bad_srat:
- bad_srat();
-out_err:
- return -EINVAL;
-}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 05e3795..eb73fda 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -27,6 +27,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/acpi.h>
+#include <linux/memblock.h>
#include <linux/numa.h>
#include <linux/nodemask.h>
#include <linux/topology.h>
@@ -240,6 +241,62 @@ void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
}
}
+/*
+ * Default callback for parsing of the Proximity Domain <-> Memory
+ * Area mappings
+ */
+int __init __weak
+acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ u32 hotpluggable;
+ int node, pxm;
+
+ if (srat_disabled())
+ goto out_err;
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
+ goto out_err_bad_srat;
+ if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
+ goto out_err;
+ hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ goto out_err;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+ if (acpi_srat_revision <= 1)
+ pxm &= 0xff;
+
+ node = acpi_map_pxm_to_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains.\n");
+ goto out_err_bad_srat;
+ }
+
+ if (numa_add_memblk(node, start, end) < 0)
+ goto out_err_bad_srat;
+
+ node_set(node, numa_nodes_parsed);
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1,
+ hotpluggable ? " hotplug" : "",
+ ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
+
+ /* Mark hotplug range in memblock. */
+ if (hotpluggable && memblock_mark_hotplug(start, ma->length))
+ pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
+ (unsigned long long)start, (unsigned long long)end - 1);
+
+ return 0;
+out_err_bad_srat:
+ bad_srat();
+out_err:
+ return -EINVAL;
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: linux-arm-kernel
From: Hanjun Guo <hanjun.guo@linaro.org>
After the cleanup for acpi_numa_memory_affinity_init(),
it can be used for architetures both x86 and arm64, since
CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
worry about that.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
arch/x86/mm/srat.c | 54 ----------------------------------------
drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 96 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 03ac1b9..5c01b06 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -137,48 +137,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
pxm, mpidr, node, cpus_in_srat);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- int node, pxm;
-
- if (srat_disabled())
- return -EINVAL;
-
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
- bad_srat();
- return -EINVAL;
- }
-
- /* Ignore disabled entries */
- if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
- return -EINVAL;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
-
- node = acpi_map_pxm_to_node(pxm);
-
- if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
- pr_err("SRAT: Too many proximity domains.\n");
- bad_srat();
- return -EINVAL;
- }
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1);
-
- if (numa_add_memblk(node, start, end) < 0) {
- bad_srat();
- return -EINVAL;
- }
-
- return 0;
-}
-
int __init arm64_acpi_numa_init(void)
{
int ret;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index af1dc14..cbd792f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/topology.h>
#include <linux/bootmem.h>
-#include <linux/memblock.h>
#include <linux/mm.h>
#include <asm/proto.h>
#include <asm/numa.h>
@@ -104,59 +103,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init
-acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- u32 hotpluggable;
- int node, pxm;
-
- if (srat_disabled())
- goto out_err;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
- goto out_err_bad_srat;
- if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
- goto out_err;
- hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
- goto out_err;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
- if (acpi_srat_revision <= 1)
- pxm &= 0xff;
-
- node = acpi_map_pxm_to_node(pxm);
- if (node < 0) {
- printk(KERN_ERR "SRAT: Too many proximity domains.\n");
- goto out_err_bad_srat;
- }
-
- if (numa_add_memblk(node, start, end) < 0)
- goto out_err_bad_srat;
-
- node_set(node, numa_nodes_parsed);
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1,
- hotpluggable ? " hotplug" : "",
- ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
-
- /* Mark hotplug range in memblock. */
- if (hotpluggable && memblock_mark_hotplug(start, ma->length))
- pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
- (unsigned long long)start, (unsigned long long)end - 1);
-
- return 0;
-out_err_bad_srat:
- bad_srat();
-out_err:
- return -EINVAL;
-}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 05e3795..eb73fda 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -27,6 +27,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/acpi.h>
+#include <linux/memblock.h>
#include <linux/numa.h>
#include <linux/nodemask.h>
#include <linux/topology.h>
@@ -240,6 +241,62 @@ void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
}
}
+/*
+ * Default callback for parsing of the Proximity Domain <-> Memory
+ * Area mappings
+ */
+int __init __weak
+acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ u32 hotpluggable;
+ int node, pxm;
+
+ if (srat_disabled())
+ goto out_err;
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
+ goto out_err_bad_srat;
+ if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
+ goto out_err;
+ hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ goto out_err;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+ if (acpi_srat_revision <= 1)
+ pxm &= 0xff;
+
+ node = acpi_map_pxm_to_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains.\n");
+ goto out_err_bad_srat;
+ }
+
+ if (numa_add_memblk(node, start, end) < 0)
+ goto out_err_bad_srat;
+
+ node_set(node, numa_nodes_parsed);
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1,
+ hotpluggable ? " hotplug" : "",
+ ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
+
+ /* Mark hotplug range in memblock. */
+ if (hotpluggable && memblock_mark_hotplug(start, ma->length))
+ pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
+ (unsigned long long)start, (unsigned long long)end - 1);
+
+ return 0;
+out_err_bad_srat:
+ bad_srat();
+out_err:
+ return -EINVAL;
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-23 9:39 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-23 9:39 UTC (permalink / raw)
To: Rafael J. Wysocki, Will Deacon, Catalin Marinas
Cc: linux-acpi, linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Robert Richter, Hanjun Guo
From: Hanjun Guo <hanjun.guo@linaro.org>
After the cleanup for acpi_numa_memory_affinity_init(),
it can be used for architetures both x86 and arm64, since
CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
worry about that.
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
arch/x86/mm/srat.c | 54 ----------------------------------------
drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 57 insertions(+), 96 deletions(-)
diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c
index 03ac1b9..5c01b06 100644
--- a/arch/arm64/kernel/acpi_numa.c
+++ b/arch/arm64/kernel/acpi_numa.c
@@ -137,48 +137,6 @@ void __init acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa)
pxm, mpidr, node, cpus_in_srat);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- int node, pxm;
-
- if (srat_disabled())
- return -EINVAL;
-
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
- bad_srat();
- return -EINVAL;
- }
-
- /* Ignore disabled entries */
- if (!(ma->flags & ACPI_SRAT_MEM_ENABLED))
- return -EINVAL;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
-
- node = acpi_map_pxm_to_node(pxm);
-
- if (node == NUMA_NO_NODE || node >= MAX_NUMNODES) {
- pr_err("SRAT: Too many proximity domains.\n");
- bad_srat();
- return -EINVAL;
- }
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1);
-
- if (numa_add_memblk(node, start, end) < 0) {
- bad_srat();
- return -EINVAL;
- }
-
- return 0;
-}
-
int __init arm64_acpi_numa_init(void)
{
int ret;
diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
index af1dc14..cbd792f 100644
--- a/arch/x86/mm/srat.c
+++ b/arch/x86/mm/srat.c
@@ -16,7 +16,6 @@
#include <linux/module.h>
#include <linux/topology.h>
#include <linux/bootmem.h>
-#include <linux/memblock.h>
#include <linux/mm.h>
#include <asm/proto.h>
#include <asm/numa.h>
@@ -104,59 +103,6 @@ acpi_numa_processor_affinity_init(struct acpi_srat_cpu_affinity *pa)
pxm, apic_id, node);
}
-/* Callback for parsing of the Proximity Domain <-> Memory Area mappings */
-int __init
-acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
-{
- u64 start, end;
- u32 hotpluggable;
- int node, pxm;
-
- if (srat_disabled())
- goto out_err;
- if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
- goto out_err_bad_srat;
- if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
- goto out_err;
- hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
- if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
- goto out_err;
-
- start = ma->base_address;
- end = start + ma->length;
- pxm = ma->proximity_domain;
- if (acpi_srat_revision <= 1)
- pxm &= 0xff;
-
- node = acpi_map_pxm_to_node(pxm);
- if (node < 0) {
- printk(KERN_ERR "SRAT: Too many proximity domains.\n");
- goto out_err_bad_srat;
- }
-
- if (numa_add_memblk(node, start, end) < 0)
- goto out_err_bad_srat;
-
- node_set(node, numa_nodes_parsed);
-
- pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
- node, pxm,
- (unsigned long long) start, (unsigned long long) end - 1,
- hotpluggable ? " hotplug" : "",
- ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
-
- /* Mark hotplug range in memblock. */
- if (hotpluggable && memblock_mark_hotplug(start, ma->length))
- pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
- (unsigned long long)start, (unsigned long long)end - 1);
-
- return 0;
-out_err_bad_srat:
- bad_srat();
-out_err:
- return -EINVAL;
-}
-
int __init x86_acpi_numa_init(void)
{
int ret;
diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c
index 05e3795..eb73fda 100644
--- a/drivers/acpi/numa.c
+++ b/drivers/acpi/numa.c
@@ -27,6 +27,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/acpi.h>
+#include <linux/memblock.h>
#include <linux/numa.h>
#include <linux/nodemask.h>
#include <linux/topology.h>
@@ -240,6 +241,62 @@ void __init __weak acpi_numa_slit_init(struct acpi_table_slit *slit)
}
}
+/*
+ * Default callback for parsing of the Proximity Domain <-> Memory
+ * Area mappings
+ */
+int __init __weak
+acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
+{
+ u64 start, end;
+ u32 hotpluggable;
+ int node, pxm;
+
+ if (srat_disabled())
+ goto out_err;
+ if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
+ goto out_err_bad_srat;
+ if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
+ goto out_err;
+ hotpluggable = ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE;
+ if (hotpluggable && !IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ goto out_err;
+
+ start = ma->base_address;
+ end = start + ma->length;
+ pxm = ma->proximity_domain;
+ if (acpi_srat_revision <= 1)
+ pxm &= 0xff;
+
+ node = acpi_map_pxm_to_node(pxm);
+ if (node < 0) {
+ printk(KERN_ERR "SRAT: Too many proximity domains.\n");
+ goto out_err_bad_srat;
+ }
+
+ if (numa_add_memblk(node, start, end) < 0)
+ goto out_err_bad_srat;
+
+ node_set(node, numa_nodes_parsed);
+
+ pr_info("SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]%s%s\n",
+ node, pxm,
+ (unsigned long long) start, (unsigned long long) end - 1,
+ hotpluggable ? " hotplug" : "",
+ ma->flags & ACPI_SRAT_MEM_NON_VOLATILE ? " non-volatile" : "");
+
+ /* Mark hotplug range in memblock. */
+ if (hotpluggable && memblock_mark_hotplug(start, ma->length))
+ pr_warn("SRAT: Failed to mark hotplug range [mem %#010Lx-%#010Lx] in memblock\n",
+ (unsigned long long)start, (unsigned long long)end - 1);
+
+ return 0;
+out_err_bad_srat:
+ bad_srat();
+out_err:
+ return -EINVAL;
+}
+
static int __init acpi_parse_slit(struct acpi_table_header *table)
{
struct acpi_table_slit *slit = (struct acpi_table_slit *)table;
--
1.9.1
^ permalink raw reply related [flat|nested] 100+ messages in thread* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-23 9:39 ` Hanjun Guo
(?)
@ 2016-01-25 10:26 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:26 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:27, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> After the cleanup for acpi_numa_memory_affinity_init(),
> it can be used for architetures both x86 and arm64, since
> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> worry about that.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> arch/x86/mm/srat.c | 54 ----------------------------------------
> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 96 deletions(-)
This one reverts acpi_numa_memory_affinity_init() to the x86 version.
I rather would prefer the arm64 version for the generic code. We could
keep the x86 implementation until x86 maintainers agree to remove them
and use the generic one (implemented in a separate patch).
Doing so we can move acpi_numa_memory_affinity_init() from the
beginning to generic code (used for arm64) and have this last patch to
remove the x86 version.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-25 10:26 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:26 UTC (permalink / raw)
To: linux-arm-kernel
On 23.01.16 17:39:27, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> After the cleanup for acpi_numa_memory_affinity_init(),
> it can be used for architetures both x86 and arm64, since
> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> worry about that.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> arch/x86/mm/srat.c | 54 ----------------------------------------
> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 96 deletions(-)
This one reverts acpi_numa_memory_affinity_init() to the x86 version.
I rather would prefer the arm64 version for the generic code. We could
keep the x86 implementation until x86 maintainers agree to remove them
and use the generic one (implemented in a separate patch).
Doing so we can move acpi_numa_memory_affinity_init() from the
beginning to generic code (used for arm64) and have this last patch to
remove the x86 version.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-25 10:26 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-25 10:26 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 23.01.16 17:39:27, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> After the cleanup for acpi_numa_memory_affinity_init(),
> it can be used for architetures both x86 and arm64, since
> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> worry about that.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> arch/x86/mm/srat.c | 54 ----------------------------------------
> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 57 insertions(+), 96 deletions(-)
This one reverts acpi_numa_memory_affinity_init() to the x86 version.
I rather would prefer the arm64 version for the generic code. We could
keep the x86 implementation until x86 maintainers agree to remove them
and use the generic one (implemented in a separate patch).
Doing so we can move acpi_numa_memory_affinity_init() from the
beginning to generic code (used for arm64) and have this last patch to
remove the x86 version.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-25 10:26 ` Robert Richter
(?)
@ 2016-01-27 6:15 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:15 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
Hi Robert,
On 2016/1/25 18:26, Robert Richter wrote:
> On 23.01.16 17:39:27, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> After the cleanup for acpi_numa_memory_affinity_init(),
>> it can be used for architetures both x86 and arm64, since
>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>> worry about that.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>> arch/x86/mm/srat.c | 54 ----------------------------------------
>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 57 insertions(+), 96 deletions(-)
> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> I rather would prefer the arm64 version for the generic code. We could
> keep the x86 implementation until x86 maintainers agree to remove them
> and use the generic one (implemented in a separate patch).
>
> Doing so we can move acpi_numa_memory_affinity_init() from the
> beginning to generic code (used for arm64) and have this last patch to
> remove the x86 version.
I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
For ARM64, firmware should be careful and represent the true platform configuration to
OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
it will be not worries for the kernel.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-27 6:15 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Robert,
On 2016/1/25 18:26, Robert Richter wrote:
> On 23.01.16 17:39:27, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> After the cleanup for acpi_numa_memory_affinity_init(),
>> it can be used for architetures both x86 and arm64, since
>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>> worry about that.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>> arch/x86/mm/srat.c | 54 ----------------------------------------
>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 57 insertions(+), 96 deletions(-)
> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> I rather would prefer the arm64 version for the generic code. We could
> keep the x86 implementation until x86 maintainers agree to remove them
> and use the generic one (implemented in a separate patch).
>
> Doing so we can move acpi_numa_memory_affinity_init() from the
> beginning to generic code (used for arm64) and have this last patch to
> remove the x86 version.
I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
For ARM64, firmware should be careful and represent the true platform configuration to
OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
it will be not worries for the kernel.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-27 6:15 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-27 6:15 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
Hi Robert,
On 2016/1/25 18:26, Robert Richter wrote:
> On 23.01.16 17:39:27, Hanjun Guo wrote:
>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>
>> After the cleanup for acpi_numa_memory_affinity_init(),
>> it can be used for architetures both x86 and arm64, since
>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>> worry about that.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>> arch/x86/mm/srat.c | 54 ----------------------------------------
>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 57 insertions(+), 96 deletions(-)
> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> I rather would prefer the arm64 version for the generic code. We could
> keep the x86 implementation until x86 maintainers agree to remove them
> and use the generic one (implemented in a separate patch).
>
> Doing so we can move acpi_numa_memory_affinity_init() from the
> beginning to generic code (used for arm64) and have this last patch to
> remove the x86 version.
I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
For ARM64, firmware should be careful and represent the true platform configuration to
OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
it will be not worries for the kernel.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-27 6:15 ` Hanjun Guo
(?)
@ 2016-01-27 14:18 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:18 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 27.01.16 14:15:06, Hanjun Guo wrote:
> Hi Robert,
>
> On 2016/1/25 18:26, Robert Richter wrote:
> > On 23.01.16 17:39:27, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> After the cleanup for acpi_numa_memory_affinity_init(),
> >> it can be used for architetures both x86 and arm64, since
> >> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >> worry about that.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> ---
> >> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >> arch/x86/mm/srat.c | 54 ----------------------------------------
> >> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 57 insertions(+), 96 deletions(-)
> > This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> > I rather would prefer the arm64 version for the generic code. We could
> > keep the x86 implementation until x86 maintainers agree to remove them
> > and use the generic one (implemented in a separate patch).
> >
> > Doing so we can move acpi_numa_memory_affinity_init() from the
> > beginning to generic code (used for arm64) and have this last patch to
> > remove the x86 version.
>
> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> For ARM64, firmware should be careful and represent the true platform configuration to
> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> it will be not worries for the kernel.
But you are removing all arm64 from your first patches. Why do you
introduce acpi_numa_memory_affinity_init() in the beginning to remove
it in the end again? I esp. like the arm64 version because of its
direct returns. So I still would like to see generic code for arm64
from the beginning. Maybe have a copy of x86 initially and make
modifications for arm64 to it, or move missing code (hotplug, etc.)
from x86 to generic and remove x86 arch code with the last patch.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-27 14:18 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:18 UTC (permalink / raw)
To: linux-arm-kernel
On 27.01.16 14:15:06, Hanjun Guo wrote:
> Hi Robert,
>
> On 2016/1/25 18:26, Robert Richter wrote:
> > On 23.01.16 17:39:27, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> After the cleanup for acpi_numa_memory_affinity_init(),
> >> it can be used for architetures both x86 and arm64, since
> >> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >> worry about that.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> ---
> >> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >> arch/x86/mm/srat.c | 54 ----------------------------------------
> >> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 57 insertions(+), 96 deletions(-)
> > This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> > I rather would prefer the arm64 version for the generic code. We could
> > keep the x86 implementation until x86 maintainers agree to remove them
> > and use the generic one (implemented in a separate patch).
> >
> > Doing so we can move acpi_numa_memory_affinity_init() from the
> > beginning to generic code (used for arm64) and have this last patch to
> > remove the x86 version.
>
> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> For ARM64, firmware should be careful and represent the true platform configuration to
> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> it will be not worries for the kernel.
But you are removing all arm64 from your first patches. Why do you
introduce acpi_numa_memory_affinity_init() in the beginning to remove
it in the end again? I esp. like the arm64 version because of its
direct returns. So I still would like to see generic code for arm64
from the beginning. Maybe have a copy of x86 initially and make
modifications for arm64 to it, or move missing code (hotplug, etc.)
from x86 to generic and remove x86 arch code with the last patch.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-27 14:18 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-27 14:18 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 27.01.16 14:15:06, Hanjun Guo wrote:
> Hi Robert,
>
> On 2016/1/25 18:26, Robert Richter wrote:
> > On 23.01.16 17:39:27, Hanjun Guo wrote:
> >> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>
> >> After the cleanup for acpi_numa_memory_affinity_init(),
> >> it can be used for architetures both x86 and arm64, since
> >> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >> worry about that.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> ---
> >> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >> arch/x86/mm/srat.c | 54 ----------------------------------------
> >> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 57 insertions(+), 96 deletions(-)
> > This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> > I rather would prefer the arm64 version for the generic code. We could
> > keep the x86 implementation until x86 maintainers agree to remove them
> > and use the generic one (implemented in a separate patch).
> >
> > Doing so we can move acpi_numa_memory_affinity_init() from the
> > beginning to generic code (used for arm64) and have this last patch to
> > remove the x86 version.
>
> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> For ARM64, firmware should be careful and represent the true platform configuration to
> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> it will be not worries for the kernel.
But you are removing all arm64 from your first patches. Why do you
introduce acpi_numa_memory_affinity_init() in the beginning to remove
it in the end again? I esp. like the arm64 version because of its
direct returns. So I still would like to see generic code for arm64
from the beginning. Maybe have a copy of x86 initially and make
modifications for arm64 to it, or move missing code (hotplug, etc.)
from x86 to generic and remove x86 arch code with the last patch.
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-27 14:18 ` Robert Richter
(?)
@ 2016-01-28 2:48 ` Hanjun Guo
-1 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 2:48 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/27 22:18, Robert Richter wrote:
> On 27.01.16 14:15:06, Hanjun Guo wrote:
>> Hi Robert,
>>
>> On 2016/1/25 18:26, Robert Richter wrote:
>>> On 23.01.16 17:39:27, Hanjun Guo wrote:
>>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>>
>>>> After the cleanup for acpi_numa_memory_affinity_init(),
>>>> it can be used for architetures both x86 and arm64, since
>>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>>>> worry about that.
>>>>
>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>> ---
>>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>>>> arch/x86/mm/srat.c | 54 ----------------------------------------
>>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 57 insertions(+), 96 deletions(-)
>>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
>>> I rather would prefer the arm64 version for the generic code. We could
>>> keep the x86 implementation until x86 maintainers agree to remove them
>>> and use the generic one (implemented in a separate patch).
>>>
>>> Doing so we can move acpi_numa_memory_affinity_init() from the
>>> beginning to generic code (used for arm64) and have this last patch to
>>> remove the x86 version.
>> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
>> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
>> For ARM64, firmware should be careful and represent the true platform configuration to
>> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
>> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
>> it will be not worries for the kernel.
> But you are removing all arm64 from your first patches. Why do you
> introduce acpi_numa_memory_affinity_init() in the beginning to remove
> it in the end again? I esp. like the arm64 version because of its
> direct returns. So I still would like to see generic code for arm64
> from the beginning. Maybe have a copy of x86 initially and make
> modifications for arm64 to it, or move missing code (hotplug, etc.)
> from x86 to generic and remove x86 arch code with the last patch.
OK, so that's the logic and ordering of formatting the patch set, it's easy
to fix :)
I will introduce the generic code for acpi_numa_memory_affinity_init()
in drivers/acpi/numa.c and mark it as __weak from the beginning, and
move missing code from x86 to generic, then remove x86 one as you
suggested, is that OK?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-28 2:48 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 2:48 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/27 22:18, Robert Richter wrote:
> On 27.01.16 14:15:06, Hanjun Guo wrote:
>> Hi Robert,
>>
>> On 2016/1/25 18:26, Robert Richter wrote:
>>> On 23.01.16 17:39:27, Hanjun Guo wrote:
>>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>>
>>>> After the cleanup for acpi_numa_memory_affinity_init(),
>>>> it can be used for architetures both x86 and arm64, since
>>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>>>> worry about that.
>>>>
>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>> ---
>>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>>>> arch/x86/mm/srat.c | 54 ----------------------------------------
>>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 57 insertions(+), 96 deletions(-)
>>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
>>> I rather would prefer the arm64 version for the generic code. We could
>>> keep the x86 implementation until x86 maintainers agree to remove them
>>> and use the generic one (implemented in a separate patch).
>>>
>>> Doing so we can move acpi_numa_memory_affinity_init() from the
>>> beginning to generic code (used for arm64) and have this last patch to
>>> remove the x86 version.
>> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
>> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
>> For ARM64, firmware should be careful and represent the true platform configuration to
>> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
>> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
>> it will be not worries for the kernel.
> But you are removing all arm64 from your first patches. Why do you
> introduce acpi_numa_memory_affinity_init() in the beginning to remove
> it in the end again? I esp. like the arm64 version because of its
> direct returns. So I still would like to see generic code for arm64
> from the beginning. Maybe have a copy of x86 initially and make
> modifications for arm64 to it, or move missing code (hotplug, etc.)
> from x86 to generic and remove x86 arch code with the last patch.
OK, so that's the logic and ordering of formatting the patch set, it's easy
to fix :)
I will introduce the generic code for acpi_numa_memory_affinity_init()
in drivers/acpi/numa.c and mark it as __weak from the beginning, and
move missing code from x86 to generic, then remove x86 one as you
suggested, is that OK?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-28 2:48 ` Hanjun Guo
0 siblings, 0 replies; 100+ messages in thread
From: Hanjun Guo @ 2016-01-28 2:48 UTC (permalink / raw)
To: Robert Richter
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 2016/1/27 22:18, Robert Richter wrote:
> On 27.01.16 14:15:06, Hanjun Guo wrote:
>> Hi Robert,
>>
>> On 2016/1/25 18:26, Robert Richter wrote:
>>> On 23.01.16 17:39:27, Hanjun Guo wrote:
>>>> From: Hanjun Guo <hanjun.guo@linaro.org>
>>>>
>>>> After the cleanup for acpi_numa_memory_affinity_init(),
>>>> it can be used for architetures both x86 and arm64, since
>>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
>>>> worry about that.
>>>>
>>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>>> ---
>>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
>>>> arch/x86/mm/srat.c | 54 ----------------------------------------
>>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 57 insertions(+), 96 deletions(-)
>>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
>>> I rather would prefer the arm64 version for the generic code. We could
>>> keep the x86 implementation until x86 maintainers agree to remove them
>>> and use the generic one (implemented in a separate patch).
>>>
>>> Doing so we can move acpi_numa_memory_affinity_init() from the
>>> beginning to generic code (used for arm64) and have this last patch to
>>> remove the x86 version.
>> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
>> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
>> For ARM64, firmware should be careful and represent the true platform configuration to
>> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
>> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
>> it will be not worries for the kernel.
> But you are removing all arm64 from your first patches. Why do you
> introduce acpi_numa_memory_affinity_init() in the beginning to remove
> it in the end again? I esp. like the arm64 version because of its
> direct returns. So I still would like to see generic code for arm64
> from the beginning. Maybe have a copy of x86 initially and make
> modifications for arm64 to it, or move missing code (hotplug, etc.)
> from x86 to generic and remove x86 arch code with the last patch.
OK, so that's the logic and ordering of formatting the patch set, it's easy
to fix :)
I will introduce the generic code for acpi_numa_memory_affinity_init()
in drivers/acpi/numa.c and mark it as __weak from the beginning, and
move missing code from x86 to generic, then remove x86 one as you
suggested, is that OK?
Thanks
Hanjun
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
2016-01-28 2:48 ` Hanjun Guo
(?)
@ 2016-01-28 13:31 ` Robert Richter
-1 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-28 13:31 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 28.01.16 10:48:37, Hanjun Guo wrote:
> On 2016/1/27 22:18, Robert Richter wrote:
> > On 27.01.16 14:15:06, Hanjun Guo wrote:
> >> Hi Robert,
> >>
> >> On 2016/1/25 18:26, Robert Richter wrote:
> >>> On 23.01.16 17:39:27, Hanjun Guo wrote:
> >>>> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>>>
> >>>> After the cleanup for acpi_numa_memory_affinity_init(),
> >>>> it can be used for architetures both x86 and arm64, since
> >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >>>> worry about that.
> >>>>
> >>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>>> ---
> >>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >>>> arch/x86/mm/srat.c | 54 ----------------------------------------
> >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >>>> 3 files changed, 57 insertions(+), 96 deletions(-)
> >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> >>> I rather would prefer the arm64 version for the generic code. We could
> >>> keep the x86 implementation until x86 maintainers agree to remove them
> >>> and use the generic one (implemented in a separate patch).
> >>>
> >>> Doing so we can move acpi_numa_memory_affinity_init() from the
> >>> beginning to generic code (used for arm64) and have this last patch to
> >>> remove the x86 version.
> >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> >> For ARM64, firmware should be careful and represent the true platform configuration to
> >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> >> it will be not worries for the kernel.
> > But you are removing all arm64 from your first patches. Why do you
> > introduce acpi_numa_memory_affinity_init() in the beginning to remove
> > it in the end again? I esp. like the arm64 version because of its
> > direct returns. So I still would like to see generic code for arm64
> > from the beginning. Maybe have a copy of x86 initially and make
> > modifications for arm64 to it, or move missing code (hotplug, etc.)
> > from x86 to generic and remove x86 arch code with the last patch.
>
> OK, so that's the logic and ordering of formatting the patch set, it's easy
> to fix :)
>
> I will introduce the generic code for acpi_numa_memory_affinity_init()
> in drivers/acpi/numa.c and mark it as __weak from the beginning, and
> move missing code from x86 to generic, then remove x86 one as you
> suggested, is that OK?
Sounds good to me. Awaiting your updated version. :)
Btw, I tested the whole series, so:
Tested-by: Robert Richter <rrichter@cavium.com>
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-28 13:31 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-28 13:31 UTC (permalink / raw)
To: linux-arm-kernel
On 28.01.16 10:48:37, Hanjun Guo wrote:
> On 2016/1/27 22:18, Robert Richter wrote:
> > On 27.01.16 14:15:06, Hanjun Guo wrote:
> >> Hi Robert,
> >>
> >> On 2016/1/25 18:26, Robert Richter wrote:
> >>> On 23.01.16 17:39:27, Hanjun Guo wrote:
> >>>> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>>>
> >>>> After the cleanup for acpi_numa_memory_affinity_init(),
> >>>> it can be used for architetures both x86 and arm64, since
> >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >>>> worry about that.
> >>>>
> >>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>>> ---
> >>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >>>> arch/x86/mm/srat.c | 54 ----------------------------------------
> >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >>>> 3 files changed, 57 insertions(+), 96 deletions(-)
> >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> >>> I rather would prefer the arm64 version for the generic code. We could
> >>> keep the x86 implementation until x86 maintainers agree to remove them
> >>> and use the generic one (implemented in a separate patch).
> >>>
> >>> Doing so we can move acpi_numa_memory_affinity_init() from the
> >>> beginning to generic code (used for arm64) and have this last patch to
> >>> remove the x86 version.
> >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> >> For ARM64, firmware should be careful and represent the true platform configuration to
> >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> >> it will be not worries for the kernel.
> > But you are removing all arm64 from your first patches. Why do you
> > introduce acpi_numa_memory_affinity_init() in the beginning to remove
> > it in the end again? I esp. like the arm64 version because of its
> > direct returns. So I still would like to see generic code for arm64
> > from the beginning. Maybe have a copy of x86 initially and make
> > modifications for arm64 to it, or move missing code (hotplug, etc.)
> > from x86 to generic and remove x86 arch code with the last patch.
>
> OK, so that's the logic and ordering of formatting the patch set, it's easy
> to fix :)
>
> I will introduce the generic code for acpi_numa_memory_affinity_init()
> in drivers/acpi/numa.c and mark it as __weak from the beginning, and
> move missing code from x86 to generic, then remove x86 one as you
> suggested, is that OK?
Sounds good to me. Awaiting your updated version. :)
Btw, I tested the whole series, so:
Tested-by: Robert Richter <rrichter@cavium.com>
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH v3 12/12] acpi, numa: reuse acpi_numa_memory_affinity_init()
@ 2016-01-28 13:31 ` Robert Richter
0 siblings, 0 replies; 100+ messages in thread
From: Robert Richter @ 2016-01-28 13:31 UTC (permalink / raw)
To: Hanjun Guo
Cc: Rafael J. Wysocki, Will Deacon, Catalin Marinas, linux-acpi,
linux-arm-kernel, linux-kernel, Ganapatrao Kulkarni,
Lorenzo Pieralisi, Shannon Zhao, Steve Capper, Mark Rutland,
Hanjun Guo
On 28.01.16 10:48:37, Hanjun Guo wrote:
> On 2016/1/27 22:18, Robert Richter wrote:
> > On 27.01.16 14:15:06, Hanjun Guo wrote:
> >> Hi Robert,
> >>
> >> On 2016/1/25 18:26, Robert Richter wrote:
> >>> On 23.01.16 17:39:27, Hanjun Guo wrote:
> >>>> From: Hanjun Guo <hanjun.guo@linaro.org>
> >>>>
> >>>> After the cleanup for acpi_numa_memory_affinity_init(),
> >>>> it can be used for architetures both x86 and arm64, since
> >>>> CONFIG_MEMORY_HOTPLUG is not enabled for arm64, so no
> >>>> worry about that.
> >>>>
> >>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>>> ---
> >>>> arch/arm64/kernel/acpi_numa.c | 42 -------------------------------
> >>>> arch/x86/mm/srat.c | 54 ----------------------------------------
> >>>> drivers/acpi/numa.c | 57 +++++++++++++++++++++++++++++++++++++++++++
> >>>> 3 files changed, 57 insertions(+), 96 deletions(-)
> >>> This one reverts acpi_numa_memory_affinity_init() to the x86 version.
> >>> I rather would prefer the arm64 version for the generic code. We could
> >>> keep the x86 implementation until x86 maintainers agree to remove them
> >>> and use the generic one (implemented in a separate patch).
> >>>
> >>> Doing so we can move acpi_numa_memory_affinity_init() from the
> >>> beginning to generic code (used for arm64) and have this last patch to
> >>> remove the x86 version.
> >> I think the x86 version is the generic one, all the flags (ACPI_SRAT_MEM_HOT_PLUGGABLE and
> >> etc) are defined in the ACPI spec, x86 just use all the flags because it support such features.
> >> For ARM64, firmware should be careful and represent the true platform configuration to
> >> OS, such as on ARM64, we can't set hotpluggable flag as the ARM64 arch don't support
> >> memory hot-plug yet (also the firmware don't support it too), if firmware do things right,
> >> it will be not worries for the kernel.
> > But you are removing all arm64 from your first patches. Why do you
> > introduce acpi_numa_memory_affinity_init() in the beginning to remove
> > it in the end again? I esp. like the arm64 version because of its
> > direct returns. So I still would like to see generic code for arm64
> > from the beginning. Maybe have a copy of x86 initially and make
> > modifications for arm64 to it, or move missing code (hotplug, etc.)
> > from x86 to generic and remove x86 arch code with the last patch.
>
> OK, so that's the logic and ordering of formatting the patch set, it's easy
> to fix :)
>
> I will introduce the generic code for acpi_numa_memory_affinity_init()
> in drivers/acpi/numa.c and mark it as __weak from the beginning, and
> move missing code from x86 to generic, then remove x86 one as you
> suggested, is that OK?
Sounds good to me. Awaiting your updated version. :)
Btw, I tested the whole series, so:
Tested-by: Robert Richter <rrichter@cavium.com>
-Robert
^ permalink raw reply [flat|nested] 100+ messages in thread