2019-05-27 14:55:01 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* pSeries NUMA support
|
|
|
|
*
|
|
|
|
* Copyright (C) 2002 Anton Blanchard <anton@au.ibm.com>, IBM
|
|
|
|
*/
|
2014-10-11 00:04:49 +08:00
|
|
|
#define pr_fmt(fmt) "numa: " fmt
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/threads.h>
|
2018-10-31 06:09:49 +08:00
|
|
|
#include <linux/memblock.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/mmzone.h>
|
2011-07-23 06:24:23 +08:00
|
|
|
#include <linux/export.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/nodemask.h>
|
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/notifier.h>
|
2008-02-14 08:37:49 +08:00
|
|
|
#include <linux/of.h>
|
powerpc/mm: Fix numa reserve bootmem page selection
Fix the powerpc NUMA reserve bootmem page selection logic.
commit 8f64e1f2d1e09267ac926e15090fd505c1c0cbcb (powerpc: Reserve
in bootmem lmb reserved regions that cross NUMA nodes) changed
the logic for how the powerpc LMB reserved regions were converted
to bootmen reserved regions. As the folowing discussion reports,
the new logic was not correct.
mark_reserved_regions_for_nid() goes through each LMB on the
system that specifies a reserved area. It searches for
active regions that intersect with that LMB and are on the
specified node. It attempts to bootmem-reserve only the area
where the active region and the reserved LMB intersect. We
can not reserve things on other nodes as they may not have
bootmem structures allocated, yet.
We base the size of the bootmem reservation on two possible
things. Normally, we just make the reservation start and
stop exactly at the start and end of the LMB.
However, the LMB reservations are not aware of NUMA nodes and
on occasion a single LMB may cross into several adjacent
active regions. Those may even be on different NUMA nodes
and will require separate calls to the bootmem reserve
functions. So, the bootmem reservation must be trimmed to
fit inside the current active region.
That's all fine and dandy, but we trim the reservation
in a page-aligned fashion. That's bad because we start the
reservation at a non-page-aligned address: physbase.
The reservation may only span 2 bytes, but that those bytes
may span two pfns and cause a reserve_size of 2*PAGE_SIZE.
Take the case where you reserve 0x2 bytes at 0x0fff and
where the active region ends at 0x1000. You'll jump into
that if() statment, but node_ar.end_pfn=0x1 and
start_pfn=0x0. You'll end up with a reserve_size=0x1000,
and then call
reserve_bootmem_node(node, physbase=0xfff, size=0x1000);
0x1000 may not be on the same node as 0xfff. Oops.
In almost all the vm code, end_<anything> is not inclusive.
If you have an end_pfn of 0x1234, page 0x1234 is not
included in the range. Using PFN_UP instead of the
(>> >> PAGE_SHIFT) will make this consistent with the other VM
code.
We also need to do math for the reserved size with physbase
instead of start_pfn. node_ar.end_pfn << PAGE_SHIFT is
*precisely* the end of the node. However,
(start_pfn << PAGE_SHIFT) is *NOT* precisely the beginning
of the reserved area. That is, of course, physbase.
If we don't use physbase here, the reserve_size can be
made too large.
From: Dave Hansen <dave@linux.vnet.ibm.com>
Tested-by: Geoff Levand <geoffrey.levand@am.sony.com> Tested on PS3.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2009-02-12 20:36:04 +08:00
|
|
|
#include <linux/pfn.h>
|
2010-12-01 20:31:15 +08:00
|
|
|
#include <linux/cpuset.h>
|
|
|
|
#include <linux/node.h>
|
2013-04-24 14:02:13 +08:00
|
|
|
#include <linux/stop_machine.h>
|
2013-04-24 14:07:39 +08:00
|
|
|
#include <linux/proc_fs.h>
|
|
|
|
#include <linux/seq_file.h>
|
|
|
|
#include <linux/uaccess.h>
|
2013-04-30 10:14:20 +08:00
|
|
|
#include <linux/slab.h>
|
2013-07-25 09:13:21 +08:00
|
|
|
#include <asm/cputhreads.h>
|
2005-11-11 11:22:35 +08:00
|
|
|
#include <asm/sparsemem.h>
|
2008-02-14 08:56:49 +08:00
|
|
|
#include <asm/prom.h>
|
2005-11-07 10:18:13 +08:00
|
|
|
#include <asm/smp.h>
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
#include <asm/topology.h>
|
2010-12-01 20:31:15 +08:00
|
|
|
#include <asm/firmware.h>
|
|
|
|
#include <asm/paca.h>
|
2010-12-18 06:07:47 +08:00
|
|
|
#include <asm/hvcall.h>
|
2012-03-29 01:30:02 +08:00
|
|
|
#include <asm/setup.h>
|
2013-04-24 14:03:48 +08:00
|
|
|
#include <asm/vdso.h>
|
2017-12-02 00:47:21 +08:00
|
|
|
#include <asm/drmem.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
static int numa_enabled = 1;
|
|
|
|
|
2008-02-01 12:57:31 +08:00
|
|
|
static char *cmdline __initdata;
|
|
|
|
|
2005-11-11 11:22:35 +08:00
|
|
|
int numa_cpu_lookup_table[NR_CPUS];
|
2010-04-26 23:32:43 +08:00
|
|
|
cpumask_var_t node_to_cpumask_map[MAX_NUMNODES];
|
2005-04-17 06:20:36 +08:00
|
|
|
struct pglist_data *node_data[MAX_NUMNODES];
|
2005-11-11 11:22:35 +08:00
|
|
|
|
|
|
|
EXPORT_SYMBOL(numa_cpu_lookup_table);
|
2010-04-26 23:32:43 +08:00
|
|
|
EXPORT_SYMBOL(node_to_cpumask_map);
|
2005-11-11 11:22:35 +08:00
|
|
|
EXPORT_SYMBOL(node_data);
|
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
static int primary_domain_index;
|
2005-12-06 04:06:42 +08:00
|
|
|
static int n_mem_addr_cells, n_mem_size_cells;
|
2021-08-12 21:22:20 +08:00
|
|
|
|
|
|
|
#define FORM0_AFFINITY 0
|
|
|
|
#define FORM1_AFFINITY 1
|
2021-08-12 21:22:23 +08:00
|
|
|
#define FORM2_AFFINITY 2
|
2021-08-12 21:22:20 +08:00
|
|
|
static int affinity_form;
|
2010-05-17 04:22:31 +08:00
|
|
|
|
|
|
|
#define MAX_DISTANCE_REF_POINTS 4
|
|
|
|
static int distance_ref_points_depth;
|
2013-08-07 00:01:44 +08:00
|
|
|
static const __be32 *distance_ref_points;
|
2010-05-17 04:22:31 +08:00
|
|
|
static int distance_lookup_table[MAX_NUMNODES][MAX_DISTANCE_REF_POINTS];
|
2021-08-12 21:22:23 +08:00
|
|
|
static int numa_distance_table[MAX_NUMNODES][MAX_NUMNODES] = {
|
|
|
|
[0 ... MAX_NUMNODES - 1] = { [0 ... MAX_NUMNODES - 1] = -1 }
|
|
|
|
};
|
|
|
|
static int numa_id_index_table[MAX_NUMNODES] = { [0 ... MAX_NUMNODES - 1] = NUMA_NO_NODE };
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-04-26 23:32:43 +08:00
|
|
|
/*
|
|
|
|
* Allocate node_to_cpumask_map based on number of available nodes
|
|
|
|
* Requires node_possible_map to be valid.
|
|
|
|
*
|
2012-01-13 09:20:09 +08:00
|
|
|
* Note: cpumask_of_node() is not valid until after this is done.
|
2010-04-26 23:32:43 +08:00
|
|
|
*/
|
|
|
|
static void __init setup_node_to_cpumask_map(void)
|
|
|
|
{
|
2013-04-30 06:08:03 +08:00
|
|
|
unsigned int node;
|
2010-04-26 23:32:43 +08:00
|
|
|
|
|
|
|
/* setup nr_node_ids if not done yet */
|
2013-04-30 06:08:03 +08:00
|
|
|
if (nr_node_ids == MAX_NUMNODES)
|
|
|
|
setup_nr_node_ids();
|
2010-04-26 23:32:43 +08:00
|
|
|
|
|
|
|
/* allocate the map */
|
2015-11-06 10:46:29 +08:00
|
|
|
for_each_node(node)
|
2010-04-26 23:32:43 +08:00
|
|
|
alloc_bootmem_cpumask_var(&node_to_cpumask_map[node]);
|
|
|
|
|
|
|
|
/* cpumask_of_node() will now work */
|
2021-08-26 18:05:17 +08:00
|
|
|
pr_debug("Node to cpumask map for %u nodes\n", nr_node_ids);
|
2010-04-26 23:32:43 +08:00
|
|
|
}
|
|
|
|
|
2013-03-26 02:44:44 +08:00
|
|
|
static int __init fake_numa_create_new_node(unsigned long end_pfn,
|
2008-02-01 12:57:31 +08:00
|
|
|
unsigned int *nid)
|
|
|
|
{
|
|
|
|
unsigned long long mem;
|
|
|
|
char *p = cmdline;
|
|
|
|
static unsigned int fake_nid;
|
|
|
|
static unsigned long long curr_boundary;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Modify node id, iff we started creating NUMA nodes
|
|
|
|
* We want to continue from where we left of the last time
|
|
|
|
*/
|
|
|
|
if (fake_nid)
|
|
|
|
*nid = fake_nid;
|
|
|
|
/*
|
|
|
|
* In case there are no more arguments to parse, the
|
|
|
|
* node_id should be the same as the last fake node id
|
|
|
|
* (we've handled this above).
|
|
|
|
*/
|
|
|
|
if (!p)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
mem = memparse(p, &p);
|
|
|
|
if (!mem)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (mem < curr_boundary)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
curr_boundary = mem;
|
|
|
|
|
|
|
|
if ((end_pfn << PAGE_SHIFT) > mem) {
|
|
|
|
/*
|
|
|
|
* Skip commas and spaces
|
|
|
|
*/
|
|
|
|
while (*p == ',' || *p == ' ' || *p == '\t')
|
|
|
|
p++;
|
|
|
|
|
|
|
|
cmdline = p;
|
|
|
|
fake_nid++;
|
|
|
|
*nid = fake_nid;
|
2021-08-26 18:05:17 +08:00
|
|
|
pr_debug("created new fake_node with id %d\n", fake_nid);
|
2008-02-01 12:57:31 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:18 +08:00
|
|
|
static void __init reset_numa_cpu_lookup_table(void)
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
{
|
|
|
|
unsigned int cpu;
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu)
|
|
|
|
numa_cpu_lookup_table[cpu] = -1;
|
|
|
|
}
|
|
|
|
|
2021-08-26 18:05:20 +08:00
|
|
|
void map_cpu_to_node(int cpu, int node)
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
{
|
|
|
|
update_numa_cpu_lookup_table(cpu, node);
|
2005-11-11 11:22:35 +08:00
|
|
|
|
2021-08-26 18:05:19 +08:00
|
|
|
if (!(cpumask_test_cpu(cpu, node_to_cpumask_map[node]))) {
|
|
|
|
pr_debug("adding cpu %d to node %d\n", cpu, node);
|
2010-04-26 23:32:43 +08:00
|
|
|
cpumask_set_cpu(cpu, node_to_cpumask_map[node]);
|
2021-08-26 18:05:19 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-12-18 06:07:47 +08:00
|
|
|
#if defined(CONFIG_HOTPLUG_CPU) || defined(CONFIG_PPC_SPLPAR)
|
2021-08-26 18:05:20 +08:00
|
|
|
void unmap_cpu_from_node(unsigned long cpu)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int node = numa_cpu_lookup_table[cpu];
|
|
|
|
|
2010-04-26 23:32:43 +08:00
|
|
|
if (cpumask_test_cpu(cpu, node_to_cpumask_map[node])) {
|
2011-01-29 20:37:16 +08:00
|
|
|
cpumask_clear_cpu(cpu, node_to_cpumask_map[node]);
|
2021-08-26 18:05:19 +08:00
|
|
|
pr_debug("removing cpu %lu from node %d\n", cpu, node);
|
2005-04-17 06:20:36 +08:00
|
|
|
} else {
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_warn("Warning: cpu %lu not found in node %d\n", cpu, node);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
}
|
2010-12-18 06:07:47 +08:00
|
|
|
#endif /* CONFIG_HOTPLUG_CPU || CONFIG_PPC_SPLPAR */
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-12 21:22:23 +08:00
|
|
|
static int __associativity_to_nid(const __be32 *associativity,
|
|
|
|
int max_array_sz)
|
|
|
|
{
|
|
|
|
int nid;
|
|
|
|
/*
|
|
|
|
* primary_domain_index is 1 based array index.
|
|
|
|
*/
|
|
|
|
int index = primary_domain_index - 1;
|
|
|
|
|
|
|
|
if (!numa_enabled || index >= max_array_sz)
|
|
|
|
return NUMA_NO_NODE;
|
|
|
|
|
|
|
|
nid = of_read_number(&associativity[index], 1);
|
|
|
|
|
|
|
|
/* POWER4 LPAR uses 0xffff as invalid node */
|
|
|
|
if (nid == 0xffff || nid >= nr_node_ids)
|
|
|
|
nid = NUMA_NO_NODE;
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* Returns nid in the range [0..nr_node_ids], or -1 if no useful NUMA
|
|
|
|
* info is found.
|
|
|
|
*/
|
|
|
|
static int associativity_to_nid(const __be32 *associativity)
|
|
|
|
{
|
|
|
|
int array_sz = of_read_number(associativity, 1);
|
|
|
|
|
|
|
|
/* Skip the first element in the associativity array */
|
|
|
|
return __associativity_to_nid((associativity + 1), array_sz);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __cpu_form2_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
|
|
|
|
{
|
|
|
|
int dist;
|
|
|
|
int node1, node2;
|
|
|
|
|
|
|
|
node1 = associativity_to_nid(cpu1_assoc);
|
|
|
|
node2 = associativity_to_nid(cpu2_assoc);
|
|
|
|
|
|
|
|
dist = numa_distance_table[node1][node2];
|
|
|
|
if (dist <= LOCAL_DISTANCE)
|
|
|
|
return 0;
|
|
|
|
else if (dist <= REMOTE_DISTANCE)
|
|
|
|
return 1;
|
|
|
|
else
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:22 +08:00
|
|
|
static int __cpu_form1_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
|
2019-07-04 01:04:00 +08:00
|
|
|
{
|
|
|
|
int dist = 0;
|
|
|
|
|
|
|
|
int i, index;
|
|
|
|
|
|
|
|
for (i = 0; i < distance_ref_points_depth; i++) {
|
|
|
|
index = be32_to_cpu(distance_ref_points[i]);
|
|
|
|
if (cpu1_assoc[index] == cpu2_assoc[index])
|
|
|
|
break;
|
|
|
|
dist++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return dist;
|
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:22 +08:00
|
|
|
int cpu_relative_distance(__be32 *cpu1_assoc, __be32 *cpu2_assoc)
|
|
|
|
{
|
|
|
|
/* We should not get called with FORM0 */
|
|
|
|
VM_WARN_ON(affinity_form == FORM0_AFFINITY);
|
2021-08-12 21:22:23 +08:00
|
|
|
if (affinity_form == FORM1_AFFINITY)
|
|
|
|
return __cpu_form1_relative_distance(cpu1_assoc, cpu2_assoc);
|
|
|
|
return __cpu_form2_relative_distance(cpu1_assoc, cpu2_assoc);
|
2021-08-12 21:22:22 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* must hold reference to node during call */
|
2013-08-07 00:01:44 +08:00
|
|
|
static const __be32 *of_get_associativity(struct device_node *dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-04-03 20:26:41 +08:00
|
|
|
return of_get_property(dev, "ibm,associativity", NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2010-05-17 04:22:31 +08:00
|
|
|
int __node_distance(int a, int b)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
int distance = LOCAL_DISTANCE;
|
|
|
|
|
2021-08-12 21:22:23 +08:00
|
|
|
if (affinity_form == FORM2_AFFINITY)
|
|
|
|
return numa_distance_table[a][b];
|
|
|
|
else if (affinity_form == FORM0_AFFINITY)
|
2013-03-22 13:49:35 +08:00
|
|
|
return ((a == b) ? LOCAL_DISTANCE : REMOTE_DISTANCE);
|
2010-05-17 04:22:31 +08:00
|
|
|
|
|
|
|
for (i = 0; i < distance_ref_points_depth; i++) {
|
|
|
|
if (distance_lookup_table[a][i] == distance_lookup_table[b][i])
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Double the distance for each NUMA level */
|
|
|
|
distance *= 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
return distance;
|
|
|
|
}
|
2014-04-19 06:07:14 +08:00
|
|
|
EXPORT_SYMBOL(__node_distance);
|
2010-05-17 04:22:31 +08:00
|
|
|
|
2010-12-01 20:31:15 +08:00
|
|
|
/* Returns the nid associated with the given device tree node,
|
|
|
|
* or -1 if not found.
|
|
|
|
*/
|
|
|
|
static int of_node_to_nid_single(struct device_node *device)
|
|
|
|
{
|
2019-03-06 07:42:58 +08:00
|
|
|
int nid = NUMA_NO_NODE;
|
2013-08-07 00:01:44 +08:00
|
|
|
const __be32 *tmp;
|
2010-12-01 20:31:15 +08:00
|
|
|
|
|
|
|
tmp = of_get_associativity(device);
|
|
|
|
if (tmp)
|
|
|
|
nid = associativity_to_nid(tmp);
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
2006-05-02 03:16:12 +08:00
|
|
|
/* Walk the device tree upwards, looking for an associativity id */
|
|
|
|
int of_node_to_nid(struct device_node *device)
|
|
|
|
{
|
2019-03-06 07:42:58 +08:00
|
|
|
int nid = NUMA_NO_NODE;
|
2006-05-02 03:16:12 +08:00
|
|
|
|
|
|
|
of_node_get(device);
|
|
|
|
while (device) {
|
|
|
|
nid = of_node_to_nid_single(device);
|
|
|
|
if (nid != -1)
|
|
|
|
break;
|
|
|
|
|
2015-10-12 04:23:27 +08:00
|
|
|
device = of_get_next_parent(device);
|
2006-05-02 03:16:12 +08:00
|
|
|
}
|
|
|
|
of_node_put(device);
|
|
|
|
|
|
|
|
return nid;
|
|
|
|
}
|
2017-02-02 06:52:42 +08:00
|
|
|
EXPORT_SYMBOL(of_node_to_nid);
|
2006-05-02 03:16:12 +08:00
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
static void __initialize_form1_numa_distance(const __be32 *associativity,
|
|
|
|
int max_array_sz)
|
|
|
|
{
|
|
|
|
int i, nid;
|
|
|
|
|
|
|
|
if (affinity_form != FORM1_AFFINITY)
|
|
|
|
return;
|
|
|
|
|
|
|
|
nid = __associativity_to_nid(associativity, max_array_sz);
|
|
|
|
if (nid != NUMA_NO_NODE) {
|
|
|
|
for (i = 0; i < distance_ref_points_depth; i++) {
|
|
|
|
const __be32 *entry;
|
|
|
|
int index = be32_to_cpu(distance_ref_points[i]) - 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* broken hierarchy, return with broken distance table
|
|
|
|
*/
|
|
|
|
if (WARN(index >= max_array_sz, "Broken ibm,associativity property"))
|
|
|
|
return;
|
|
|
|
|
|
|
|
entry = &associativity[index];
|
|
|
|
distance_lookup_table[nid][i] = of_read_number(entry, 1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void initialize_form1_numa_distance(const __be32 *associativity)
|
|
|
|
{
|
|
|
|
int array_sz;
|
|
|
|
|
|
|
|
array_sz = of_read_number(associativity, 1);
|
|
|
|
/* Skip the first element in the associativity array */
|
|
|
|
__initialize_form1_numa_distance(associativity + 1, array_sz);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Used to update distance information w.r.t newly added node.
|
|
|
|
*/
|
|
|
|
void update_numa_distance(struct device_node *node)
|
|
|
|
{
|
2021-08-12 21:22:23 +08:00
|
|
|
int nid;
|
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
if (affinity_form == FORM0_AFFINITY)
|
|
|
|
return;
|
|
|
|
else if (affinity_form == FORM1_AFFINITY) {
|
|
|
|
const __be32 *associativity;
|
|
|
|
|
|
|
|
associativity = of_get_associativity(node);
|
|
|
|
if (!associativity)
|
|
|
|
return;
|
|
|
|
|
|
|
|
initialize_form1_numa_distance(associativity);
|
|
|
|
return;
|
|
|
|
}
|
2021-08-12 21:22:23 +08:00
|
|
|
|
|
|
|
/* FORM2 affinity */
|
|
|
|
nid = of_node_to_nid_single(node);
|
|
|
|
if (nid == NUMA_NO_NODE)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* With FORM2 we expect NUMA distance of all possible NUMA
|
|
|
|
* nodes to be provided during boot.
|
|
|
|
*/
|
|
|
|
WARN(numa_distance_table[nid][nid] == -1,
|
|
|
|
"NUMA distance details for node %d not provided\n", nid);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ibm,numa-lookup-index-table= {N, domainid1, domainid2, ..... domainidN}
|
|
|
|
* ibm,numa-distance-table = { N, 1, 2, 4, 5, 1, 6, .... N elements}
|
|
|
|
*/
|
2021-12-17 06:00:18 +08:00
|
|
|
static void __init initialize_form2_numa_distance_lookup_table(void)
|
2021-08-12 21:22:23 +08:00
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
struct device_node *root;
|
2021-11-09 14:48:59 +08:00
|
|
|
const __u8 *form2_distances;
|
2021-08-12 21:22:23 +08:00
|
|
|
const __be32 *numa_lookup_index;
|
2021-11-09 14:48:59 +08:00
|
|
|
int form2_distances_length;
|
2021-08-12 21:22:23 +08:00
|
|
|
int max_numa_index, distance_index;
|
|
|
|
|
|
|
|
if (firmware_has_feature(FW_FEATURE_OPAL))
|
|
|
|
root = of_find_node_by_path("/ibm,opal");
|
|
|
|
else
|
|
|
|
root = of_find_node_by_path("/rtas");
|
|
|
|
if (!root)
|
|
|
|
root = of_find_node_by_path("/");
|
|
|
|
|
|
|
|
numa_lookup_index = of_get_property(root, "ibm,numa-lookup-index-table", NULL);
|
|
|
|
max_numa_index = of_read_number(&numa_lookup_index[0], 1);
|
|
|
|
|
|
|
|
/* first element of the array is the size and is encode-int */
|
2021-11-09 14:48:59 +08:00
|
|
|
form2_distances = of_get_property(root, "ibm,numa-distance-table", NULL);
|
|
|
|
form2_distances_length = of_read_number((const __be32 *)&form2_distances[0], 1);
|
2021-08-12 21:22:23 +08:00
|
|
|
/* Skip the size which is encoded int */
|
2021-11-09 14:48:59 +08:00
|
|
|
form2_distances += sizeof(__be32);
|
2021-08-12 21:22:23 +08:00
|
|
|
|
2021-11-09 14:48:59 +08:00
|
|
|
pr_debug("form2_distances_len = %d, numa_dist_indexes_len = %d\n",
|
|
|
|
form2_distances_length, max_numa_index);
|
2021-08-12 21:22:23 +08:00
|
|
|
|
|
|
|
for (i = 0; i < max_numa_index; i++)
|
|
|
|
/* +1 skip the max_numa_index in the property */
|
|
|
|
numa_id_index_table[i] = of_read_number(&numa_lookup_index[i + 1], 1);
|
|
|
|
|
|
|
|
|
2021-11-09 14:48:59 +08:00
|
|
|
if (form2_distances_length != max_numa_index * max_numa_index) {
|
2021-08-12 21:22:23 +08:00
|
|
|
WARN(1, "Wrong NUMA distance information\n");
|
2021-11-09 14:49:00 +08:00
|
|
|
form2_distances = NULL; // don't use it
|
2021-08-12 21:22:23 +08:00
|
|
|
}
|
|
|
|
distance_index = 0;
|
|
|
|
for (i = 0; i < max_numa_index; i++) {
|
|
|
|
for (j = 0; j < max_numa_index; j++) {
|
|
|
|
int nodeA = numa_id_index_table[i];
|
|
|
|
int nodeB = numa_id_index_table[j];
|
2021-11-09 14:49:00 +08:00
|
|
|
int dist;
|
|
|
|
|
|
|
|
if (form2_distances)
|
|
|
|
dist = form2_distances[distance_index++];
|
|
|
|
else if (nodeA == nodeB)
|
|
|
|
dist = LOCAL_DISTANCE;
|
|
|
|
else
|
|
|
|
dist = REMOTE_DISTANCE;
|
|
|
|
numa_distance_table[nodeA][nodeB] = dist;
|
|
|
|
pr_debug("dist[%d][%d]=%d ", nodeA, nodeB, dist);
|
2021-08-12 21:22:23 +08:00
|
|
|
}
|
|
|
|
}
|
2021-11-09 14:49:00 +08:00
|
|
|
|
2021-08-12 21:22:23 +08:00
|
|
|
of_node_put(root);
|
2021-08-12 21:22:21 +08:00
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
static int __init find_primary_domain_index(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2021-08-12 21:22:19 +08:00
|
|
|
int index;
|
2011-04-11 04:42:05 +08:00
|
|
|
struct device_node *root;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-12 21:22:20 +08:00
|
|
|
/*
|
|
|
|
* Check for which form of affinity.
|
|
|
|
*/
|
|
|
|
if (firmware_has_feature(FW_FEATURE_OPAL)) {
|
|
|
|
affinity_form = FORM1_AFFINITY;
|
2021-08-12 21:22:23 +08:00
|
|
|
} else if (firmware_has_feature(FW_FEATURE_FORM2_AFFINITY)) {
|
2021-08-26 18:05:17 +08:00
|
|
|
pr_debug("Using form 2 affinity\n");
|
2021-08-12 21:22:23 +08:00
|
|
|
affinity_form = FORM2_AFFINITY;
|
2021-08-12 21:22:20 +08:00
|
|
|
} else if (firmware_has_feature(FW_FEATURE_FORM1_AFFINITY)) {
|
2021-08-26 18:05:17 +08:00
|
|
|
pr_debug("Using form 1 affinity\n");
|
2021-08-12 21:22:20 +08:00
|
|
|
affinity_form = FORM1_AFFINITY;
|
|
|
|
} else
|
|
|
|
affinity_form = FORM0_AFFINITY;
|
|
|
|
|
2011-10-28 12:25:32 +08:00
|
|
|
if (firmware_has_feature(FW_FEATURE_OPAL))
|
|
|
|
root = of_find_node_by_path("/ibm,opal");
|
|
|
|
else
|
|
|
|
root = of_find_node_by_path("/rtas");
|
2011-04-11 04:42:05 +08:00
|
|
|
if (!root)
|
|
|
|
root = of_find_node_by_path("/");
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
2010-05-17 04:22:31 +08:00
|
|
|
* This property is a set of 32-bit integers, each representing
|
|
|
|
* an index into the ibm,associativity nodes.
|
|
|
|
*
|
|
|
|
* With form 0 affinity the first integer is for an SMP configuration
|
|
|
|
* (should be all 0's) and the second is for a normal NUMA
|
|
|
|
* configuration. We have only one level of NUMA.
|
|
|
|
*
|
|
|
|
* With form 1 affinity the first integer is the most significant
|
|
|
|
* NUMA boundary and the following are progressively less significant
|
|
|
|
* boundaries. There can be more than one level of NUMA.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2011-04-11 04:42:05 +08:00
|
|
|
distance_ref_points = of_get_property(root,
|
2010-05-17 04:22:31 +08:00
|
|
|
"ibm,associativity-reference-points",
|
|
|
|
&distance_ref_points_depth);
|
|
|
|
|
|
|
|
if (!distance_ref_points) {
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_debug("ibm,associativity-reference-points not found.\n");
|
2010-05-17 04:22:31 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
distance_ref_points_depth /= sizeof(int);
|
2021-08-12 21:22:20 +08:00
|
|
|
if (affinity_form == FORM0_AFFINITY) {
|
2010-05-17 04:22:31 +08:00
|
|
|
if (distance_ref_points_depth < 2) {
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_warn("short ibm,associativity-reference-points\n");
|
2010-05-17 04:22:31 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
index = of_read_number(&distance_ref_points[1], 1);
|
2021-08-12 21:22:20 +08:00
|
|
|
} else {
|
2021-08-12 21:22:23 +08:00
|
|
|
/*
|
|
|
|
* Both FORM1 and FORM2 affinity find the primary domain details
|
|
|
|
* at the same offset.
|
|
|
|
*/
|
2021-08-12 21:22:20 +08:00
|
|
|
index = of_read_number(distance_ref_points, 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2010-05-17 04:22:31 +08:00
|
|
|
/*
|
|
|
|
* Warn and cap if the hardware supports more than
|
|
|
|
* MAX_DISTANCE_REF_POINTS domains.
|
|
|
|
*/
|
|
|
|
if (distance_ref_points_depth > MAX_DISTANCE_REF_POINTS) {
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_warn("distance array capped at %d entries\n",
|
|
|
|
MAX_DISTANCE_REF_POINTS);
|
2010-05-17 04:22:31 +08:00
|
|
|
distance_ref_points_depth = MAX_DISTANCE_REF_POINTS;
|
|
|
|
}
|
|
|
|
|
2011-04-11 04:42:05 +08:00
|
|
|
of_node_put(root);
|
2021-08-12 21:22:19 +08:00
|
|
|
return index;
|
2010-05-17 04:22:31 +08:00
|
|
|
|
|
|
|
err:
|
2011-04-11 04:42:05 +08:00
|
|
|
of_node_put(root);
|
2010-05-17 04:22:31 +08:00
|
|
|
return -1;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-12-01 05:47:23 +08:00
|
|
|
static void __init get_n_mem_cells(int *n_addr_cells, int *n_size_cells)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct device_node *memory = NULL;
|
|
|
|
|
|
|
|
memory = of_find_node_by_type(memory, "memory");
|
2005-12-05 12:50:39 +08:00
|
|
|
if (!memory)
|
2005-12-01 05:47:23 +08:00
|
|
|
panic("numa.c: No memory nodes found!");
|
2005-12-05 12:50:39 +08:00
|
|
|
|
2007-04-03 08:56:50 +08:00
|
|
|
*n_addr_cells = of_n_addr_cells(memory);
|
2007-04-03 08:57:48 +08:00
|
|
|
*n_size_cells = of_n_size_cells(memory);
|
2005-12-01 05:47:23 +08:00
|
|
|
of_node_put(memory);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-08-07 00:01:44 +08:00
|
|
|
static unsigned long read_n_cells(int n, const __be32 **buf)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
unsigned long result = 0;
|
|
|
|
|
|
|
|
while (n--) {
|
2013-08-07 00:01:44 +08:00
|
|
|
result = (result << 32) | of_read_number(*buf, 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
(*buf)++;
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2008-07-03 11:35:54 +08:00
|
|
|
struct assoc_arrays {
|
|
|
|
u32 n_arrays;
|
|
|
|
u32 array_sz;
|
2013-08-07 00:01:44 +08:00
|
|
|
const __be32 *arrays;
|
2008-07-03 11:35:54 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2011-03-31 09:57:33 +08:00
|
|
|
* Retrieve and validate the list of associativity arrays for drconf
|
2008-07-03 11:35:54 +08:00
|
|
|
* memory from the ibm,associativity-lookup-arrays property of the
|
|
|
|
* device tree..
|
|
|
|
*
|
|
|
|
* The layout of the ibm,associativity-lookup-arrays property is a number N
|
|
|
|
* indicating the number of associativity arrays, followed by a number M
|
|
|
|
* indicating the size of each associativity array, followed by a list
|
|
|
|
* of N associativity arrays.
|
|
|
|
*/
|
2017-12-02 00:46:35 +08:00
|
|
|
static int of_get_assoc_arrays(struct assoc_arrays *aa)
|
2008-07-03 11:35:54 +08:00
|
|
|
{
|
2017-12-02 00:46:35 +08:00
|
|
|
struct device_node *memory;
|
2013-08-07 00:01:44 +08:00
|
|
|
const __be32 *prop;
|
2008-07-03 11:35:54 +08:00
|
|
|
u32 len;
|
|
|
|
|
2017-12-02 00:46:35 +08:00
|
|
|
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
|
|
|
|
if (!memory)
|
|
|
|
return -1;
|
|
|
|
|
2008-07-03 11:35:54 +08:00
|
|
|
prop = of_get_property(memory, "ibm,associativity-lookup-arrays", &len);
|
2017-12-02 00:46:35 +08:00
|
|
|
if (!prop || len < 2 * sizeof(unsigned int)) {
|
|
|
|
of_node_put(memory);
|
2008-07-03 11:35:54 +08:00
|
|
|
return -1;
|
2017-12-02 00:46:35 +08:00
|
|
|
}
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2013-08-07 00:01:44 +08:00
|
|
|
aa->n_arrays = of_read_number(prop++, 1);
|
|
|
|
aa->array_sz = of_read_number(prop++, 1);
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2017-12-02 00:46:35 +08:00
|
|
|
of_node_put(memory);
|
|
|
|
|
2011-11-29 12:31:00 +08:00
|
|
|
/* Now that we know the number of arrays and size of each array,
|
2008-07-03 11:35:54 +08:00
|
|
|
* revalidate the size of the property read in.
|
|
|
|
*/
|
|
|
|
if (len < (aa->n_arrays * aa->array_sz + 2) * sizeof(unsigned int))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
aa->arrays = prop;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-17 06:00:18 +08:00
|
|
|
static int __init get_nid_and_numa_distance(struct drmem_lmb *lmb)
|
2021-08-12 21:22:21 +08:00
|
|
|
{
|
|
|
|
struct assoc_arrays aa = { .arrays = NULL };
|
|
|
|
int default_nid = NUMA_NO_NODE;
|
|
|
|
int nid = default_nid;
|
|
|
|
int rc, index;
|
|
|
|
|
|
|
|
if ((primary_domain_index < 0) || !numa_enabled)
|
|
|
|
return default_nid;
|
|
|
|
|
|
|
|
rc = of_get_assoc_arrays(&aa);
|
|
|
|
if (rc)
|
|
|
|
return default_nid;
|
|
|
|
|
|
|
|
if (primary_domain_index <= aa.array_sz &&
|
|
|
|
!(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
|
|
|
|
const __be32 *associativity;
|
|
|
|
|
|
|
|
index = lmb->aa_index * aa.array_sz;
|
|
|
|
associativity = &aa.arrays[index];
|
|
|
|
nid = __associativity_to_nid(associativity, aa.array_sz);
|
|
|
|
if (nid > 0 && affinity_form == FORM1_AFFINITY) {
|
|
|
|
/*
|
|
|
|
* lookup array associativity entries have
|
|
|
|
* no length of the array as the first element.
|
|
|
|
*/
|
|
|
|
__initialize_form1_numa_distance(associativity, aa.array_sz);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
2008-07-03 11:35:54 +08:00
|
|
|
/*
|
|
|
|
* This is like of_node_to_nid_single() for memory represented in the
|
|
|
|
* ibm,dynamic-reconfiguration-memory node.
|
|
|
|
*/
|
pseries/hotplug-memory: hot-add: skip redundant LMB lookup
During memory hot-add, dlpar_add_lmb() calls memory_add_physaddr_to_nid()
to determine which node id (nid) to use when later calling __add_memory().
This is wasteful. On pseries, memory_add_physaddr_to_nid() finds an
appropriate nid for a given address by looking up the LMB containing the
address and then passing that LMB to of_drconf_to_nid_single() to get the
nid. In dlpar_add_lmb() we get this address from the LMB itself.
In short, we have a pointer to an LMB and then we are searching for
that LMB *again* in order to find its nid.
If we call of_drconf_to_nid_single() directly from dlpar_add_lmb() we
can skip the redundant lookup. The only error handling we need to
duplicate from memory_add_physaddr_to_nid() is the fallback to the
default nid when drconf_to_nid_single() returns -1 (NUMA_NO_NODE) or
an invalid nid.
Skipping the extra lookup makes hot-add operations faster, especially
on machines with many LMBs.
Consider an LPAR with 126976 LMBs. In one test, hot-adding 126000
LMBs on an upatched kernel took ~3.5 hours while a patched kernel
completed the same operation in ~2 hours:
Unpatched (12450 seconds):
Sep 9 04:06:31 ltc-brazos1 drmgr[810169]: drmgr: -c mem -a -q 126000
Sep 9 04:06:31 ltc-brazos1 kernel: pseries-hotplug-mem: Attempting to hot-add 126000 LMB(s)
[...]
Sep 9 07:34:01 ltc-brazos1 kernel: pseries-hotplug-mem: Memory at 20000000 (drc index 80000002) was hot-added
Patched (7065 seconds):
Sep 8 21:49:57 ltc-brazos1 drmgr[877703]: drmgr: -c mem -a -q 126000
Sep 8 21:49:57 ltc-brazos1 kernel: pseries-hotplug-mem: Attempting to hot-add 126000 LMB(s)
[...]
Sep 8 23:27:42 ltc-brazos1 kernel: pseries-hotplug-mem: Memory at 20000000 (drc index 80000002) was hot-added
It should be noted that the speedup grows more substantial when
hot-adding LMBs at the end of the drconf range. This is because we
are skipping a linear LMB search.
To see the distinction, consider smaller hot-add test on the same
LPAR. A perf-stat run with 10 iterations showed that hot-adding 4096
LMBs completed less than 1 second faster on a patched kernel:
Unpatched:
Performance counter stats for 'drmgr -c mem -a -q 4096' (10 runs):
104,753.42 msec task-clock # 0.992 CPUs utilized ( +- 0.55% )
4,708 context-switches # 0.045 K/sec ( +- 0.69% )
2,444 cpu-migrations # 0.023 K/sec ( +- 1.25% )
394 page-faults # 0.004 K/sec ( +- 0.22% )
445,902,503,057 cycles # 4.257 GHz ( +- 0.55% ) (66.67%)
8,558,376,740 stalled-cycles-frontend # 1.92% frontend cycles idle ( +- 0.88% ) (49.99%)
300,346,181,651 stalled-cycles-backend # 67.36% backend cycles idle ( +- 0.76% ) (50.01%)
258,091,488,691 instructions # 0.58 insn per cycle
# 1.16 stalled cycles per insn ( +- 0.22% ) (66.67%)
70,568,169,256 branches # 673.660 M/sec ( +- 0.17% ) (50.01%)
3,100,725,426 branch-misses # 4.39% of all branches ( +- 0.20% ) (49.99%)
105.583 +- 0.589 seconds time elapsed ( +- 0.56% )
Patched:
Performance counter stats for 'drmgr -c mem -a -q 4096' (10 runs):
104,055.69 msec task-clock # 0.993 CPUs utilized ( +- 0.32% )
4,606 context-switches # 0.044 K/sec ( +- 0.20% )
2,463 cpu-migrations # 0.024 K/sec ( +- 0.93% )
394 page-faults # 0.004 K/sec ( +- 0.25% )
442,951,129,921 cycles # 4.257 GHz ( +- 0.32% ) (66.66%)
8,710,413,329 stalled-cycles-frontend # 1.97% frontend cycles idle ( +- 0.47% ) (50.06%)
299,656,905,836 stalled-cycles-backend # 67.65% backend cycles idle ( +- 0.39% ) (50.02%)
252,731,168,193 instructions # 0.57 insn per cycle
# 1.19 stalled cycles per insn ( +- 0.20% ) (66.66%)
68,902,851,121 branches # 662.173 M/sec ( +- 0.13% ) (49.94%)
3,100,242,882 branch-misses # 4.50% of all branches ( +- 0.15% ) (49.98%)
104.829 +- 0.325 seconds time elapsed ( +- 0.31% )
This is consistent. An add-by-count hot-add operation adds LMBs
greedily, so LMBs near the start of the drconf range are considered
first. On an otherwise idle LPAR with so many LMBs we would expect to
find the LMBs we need near the start of the drconf range, hence the
smaller speedup.
Signed-off-by: Scott Cheloha <cheloha@linux.ibm.com>
Reviewed-by: Laurent Dufour <ldufour@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200916145122.3408129-1-cheloha@linux.ibm.com
2020-09-16 22:51:22 +08:00
|
|
|
int of_drconf_to_nid_single(struct drmem_lmb *lmb)
|
2008-07-03 11:35:54 +08:00
|
|
|
{
|
2017-12-02 00:46:53 +08:00
|
|
|
struct assoc_arrays aa = { .arrays = NULL };
|
2019-07-01 22:36:24 +08:00
|
|
|
int default_nid = NUMA_NO_NODE;
|
2008-07-03 11:35:54 +08:00
|
|
|
int nid = default_nid;
|
2017-12-02 00:46:53 +08:00
|
|
|
int rc, index;
|
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
if ((primary_domain_index < 0) || !numa_enabled)
|
2019-07-01 22:36:24 +08:00
|
|
|
return default_nid;
|
|
|
|
|
2017-12-02 00:46:53 +08:00
|
|
|
rc = of_get_assoc_arrays(&aa);
|
|
|
|
if (rc)
|
|
|
|
return default_nid;
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
if (primary_domain_index <= aa.array_sz &&
|
2019-07-01 22:36:24 +08:00
|
|
|
!(lmb->flags & DRCONF_MEM_AI_INVALID) && lmb->aa_index < aa.n_arrays) {
|
2021-08-12 21:22:21 +08:00
|
|
|
const __be32 *associativity;
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
index = lmb->aa_index * aa.array_sz;
|
|
|
|
associativity = &aa.arrays[index];
|
|
|
|
nid = __associativity_to_nid(associativity, aa.array_sz);
|
2008-07-03 11:35:54 +08:00
|
|
|
}
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
2020-01-29 21:53:00 +08:00
|
|
|
#ifdef CONFIG_PPC_SPLPAR
|
2021-08-12 21:22:21 +08:00
|
|
|
|
|
|
|
static int __vphn_get_associativity(long lcpu, __be32 *associativity)
|
2020-01-29 21:53:00 +08:00
|
|
|
{
|
|
|
|
long rc, hwid;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* On a shared lpar, device tree will not have node associativity.
|
|
|
|
* At this time lppaca, or its __old_status field may not be
|
|
|
|
* updated. Hence kernel cannot detect if its on a shared lpar. So
|
|
|
|
* request an explicit associativity irrespective of whether the
|
|
|
|
* lpar is shared or dedicated. Use the device tree property as a
|
|
|
|
* fallback. cpu_to_phys_id is only valid between
|
|
|
|
* smp_setup_cpu_maps() and smp_setup_pacas().
|
|
|
|
*/
|
|
|
|
if (firmware_has_feature(FW_FEATURE_VPHN)) {
|
|
|
|
if (cpu_to_phys_id)
|
|
|
|
hwid = cpu_to_phys_id[lcpu];
|
|
|
|
else
|
|
|
|
hwid = get_hard_smp_processor_id(lcpu);
|
|
|
|
|
|
|
|
rc = hcall_vphn(hwid, VPHN_FLAG_VCPU, associativity);
|
|
|
|
if (rc == H_SUCCESS)
|
2021-08-12 21:22:21 +08:00
|
|
|
return 0;
|
2020-01-29 21:53:00 +08:00
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int vphn_get_nid(long lcpu)
|
|
|
|
{
|
|
|
|
__be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
|
|
|
|
|
|
|
|
|
|
|
|
if (!__vphn_get_associativity(lcpu, associativity))
|
|
|
|
return associativity_to_nid(associativity);
|
|
|
|
|
2020-01-29 21:53:00 +08:00
|
|
|
return NUMA_NO_NODE;
|
2021-08-12 21:22:21 +08:00
|
|
|
|
2020-01-29 21:53:00 +08:00
|
|
|
}
|
|
|
|
#else
|
2021-08-12 21:22:21 +08:00
|
|
|
|
|
|
|
static int __vphn_get_associativity(long lcpu, __be32 *associativity)
|
|
|
|
{
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2020-01-29 21:53:00 +08:00
|
|
|
static int vphn_get_nid(long unused)
|
|
|
|
{
|
|
|
|
return NUMA_NO_NODE;
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_PPC_SPLPAR */
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Figure out to which domain a cpu belongs and stick it there.
|
|
|
|
* Return the id of the domain used.
|
|
|
|
*/
|
2013-06-25 03:30:09 +08:00
|
|
|
static int numa_setup_cpu(unsigned long lcpu)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
struct device_node *cpu;
|
2020-01-29 21:52:59 +08:00
|
|
|
int fcpu = cpu_first_thread_sibling(lcpu);
|
|
|
|
int nid = NUMA_NO_NODE;
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
|
2020-08-18 16:11:02 +08:00
|
|
|
if (!cpu_present(lcpu)) {
|
|
|
|
set_cpu_numa_node(lcpu, first_online_node);
|
|
|
|
return first_online_node;
|
|
|
|
}
|
|
|
|
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
/*
|
|
|
|
* If a valid cpu-to-node mapping is already available, use it
|
|
|
|
* directly instead of querying the firmware, since it represents
|
|
|
|
* the most recent mapping notified to us by the platform (eg: VPHN).
|
2020-01-29 21:52:59 +08:00
|
|
|
* Since cpu_to_node binding remains the same for all threads in the
|
|
|
|
* core. If a valid cpu-to-node mapping is already available, for
|
|
|
|
* the first thread in the core, use it.
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
*/
|
2020-01-29 21:52:59 +08:00
|
|
|
nid = numa_cpu_lookup_table[fcpu];
|
|
|
|
if (nid >= 0) {
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
map_cpu_to_node(lcpu, nid);
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
2020-01-29 21:53:00 +08:00
|
|
|
nid = vphn_get_nid(lcpu);
|
|
|
|
if (nid != NUMA_NO_NODE)
|
|
|
|
goto out_present;
|
|
|
|
|
powerpc: Fix the setup of CPU-to-Node mappings during CPU online
On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.
But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).
Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.
Now consider this scenario:
1. During boot, the kernel gets the cpu-to-node mappings from the firmware
and assigns the CPUs to NUMA nodes appropriately, during CPU online.
2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
communicates this update to the kernel. The kernel in turn updates its
cpu-to-node associations and rebuilds its sched domains. Everything is
fine so far.
3. Now, the user switches the machine from SMT to ST mode (say, by running
ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
core.
4. The user then tries to switch back from ST to SMT mode (say, by running
ppc64_cpu --smt=4), and this involves onlining those threads back. Since
CPU hotplug ignores the new mappings, it queries the firmware and tries to
associate the newly onlined sibling threads to the old NUMA nodes. This
results in sibling threads within the same core getting associated with
different NUMA nodes, which is incorrect.
The scheduler's build-sched-domains code gets thoroughly confused with this
and enters an infinite loop and causes soft-lockups, as explained in detail
in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).
So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.
Cc: stable@vger.kernel.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-12-30 19:35:34 +08:00
|
|
|
cpu = of_get_cpu_node(lcpu, NULL);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (!cpu) {
|
|
|
|
WARN_ON(1);
|
2014-08-27 17:34:01 +08:00
|
|
|
if (cpu_present(lcpu))
|
|
|
|
goto out_present;
|
|
|
|
else
|
|
|
|
goto out;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-05-02 03:16:12 +08:00
|
|
|
nid = of_node_to_nid_single(cpu);
|
2020-01-29 21:53:00 +08:00
|
|
|
of_node_put(cpu);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-08-27 17:34:01 +08:00
|
|
|
out_present:
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
if (nid < 0 || !node_possible(nid))
|
2010-03-06 05:42:43 +08:00
|
|
|
nid = first_online_node;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-01-29 21:52:59 +08:00
|
|
|
/*
|
|
|
|
* Update for the first thread of the core. All threads of a core
|
|
|
|
* have to be part of the same node. This not only avoids querying
|
|
|
|
* for every other thread in the core, but always avoids a case
|
|
|
|
* where virtual node associativity change causes subsequent threads
|
|
|
|
* of a core to be associated with different nid. However if first
|
|
|
|
* thread is already online, expect it to have a valid mapping.
|
|
|
|
*/
|
|
|
|
if (fcpu != lcpu) {
|
|
|
|
WARN_ON(cpu_online(fcpu));
|
|
|
|
map_cpu_to_node(fcpu, nid);
|
|
|
|
}
|
|
|
|
|
2014-08-27 17:34:01 +08:00
|
|
|
map_cpu_to_node(lcpu, nid);
|
|
|
|
out:
|
2006-03-21 08:35:45 +08:00
|
|
|
return nid;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2013-12-30 19:36:04 +08:00
|
|
|
static void verify_cpu_node_mapping(int cpu, int node)
|
|
|
|
{
|
|
|
|
int base, sibling, i;
|
|
|
|
|
|
|
|
/* Verify that all the threads in the core belong to the same node */
|
|
|
|
base = cpu_first_thread_sibling(cpu);
|
|
|
|
|
|
|
|
for (i = 0; i < threads_per_core; i++) {
|
|
|
|
sibling = base + i;
|
|
|
|
|
|
|
|
if (sibling == cpu || cpu_is_offline(sibling))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (cpu_to_node(sibling) != node) {
|
|
|
|
WARN(1, "CPU thread siblings %d and %d don't belong"
|
|
|
|
" to the same node!\n", cpu, sibling);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-07-18 22:07:28 +08:00
|
|
|
/* Must run before sched domains notifier. */
|
|
|
|
static int ppc_numa_cpu_prepare(unsigned int cpu)
|
|
|
|
{
|
|
|
|
int nid;
|
|
|
|
|
|
|
|
nid = numa_setup_cpu(cpu);
|
|
|
|
verify_cpu_node_mapping(cpu, nid);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ppc_numa_cpu_dead(unsigned int cpu)
|
|
|
|
{
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check and possibly modify a memory region to enforce the memory limit.
|
|
|
|
*
|
|
|
|
* Returns the size the region should have to enforce the memory limit.
|
|
|
|
* This will either be the original value of size, a truncated value,
|
|
|
|
* or zero. If the returned value of size is 0 the region should be
|
2011-03-31 09:57:33 +08:00
|
|
|
* discarded as it lies wholly above the memory limit.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2005-11-11 11:22:35 +08:00
|
|
|
static unsigned long __init numa_enforce_memory_limit(unsigned long start,
|
|
|
|
unsigned long size)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
/*
|
2010-07-12 12:36:09 +08:00
|
|
|
* We use memblock_end_of_DRAM() in here instead of memory_limit because
|
2005-04-17 06:20:36 +08:00
|
|
|
* we've already adjusted it for the limit and it takes care of
|
2008-10-20 23:37:04 +08:00
|
|
|
* having memory holes below the limit. Also, in the case of
|
|
|
|
* iommu_is_off, memory_limit is not set but is implicitly enforced.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
2010-07-12 12:36:09 +08:00
|
|
|
if (start + size <= memblock_end_of_DRAM())
|
2005-04-17 06:20:36 +08:00
|
|
|
return size;
|
|
|
|
|
2010-07-12 12:36:09 +08:00
|
|
|
if (start >= memblock_end_of_DRAM())
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
|
2010-07-12 12:36:09 +08:00
|
|
|
return memblock_end_of_DRAM() - start;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
/*
|
|
|
|
* Reads the counter for a given entry in
|
|
|
|
* linux,drconf-usable-memory property
|
|
|
|
*/
|
2013-08-07 00:01:44 +08:00
|
|
|
static inline int __init read_usm_ranges(const __be32 **usm)
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
{
|
|
|
|
/*
|
2010-07-23 08:35:52 +08:00
|
|
|
* For each lmb in ibm,dynamic-memory a corresponding
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
* entry in linux,drconf-usable-memory property contains
|
|
|
|
* a counter followed by that many (base, size) duple.
|
|
|
|
* read the counter from linux,drconf-usable-memory
|
|
|
|
*/
|
|
|
|
return read_n_cells(n_mem_size_cells, usm);
|
|
|
|
}
|
|
|
|
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
/*
|
|
|
|
* Extract NUMA information from the ibm,dynamic-reconfiguration-memory
|
|
|
|
* node. This assumes n_mem_{addr,size}_cells have been set.
|
|
|
|
*/
|
2020-07-29 19:40:32 +08:00
|
|
|
static int __init numa_setup_drmem_lmb(struct drmem_lmb *lmb,
|
|
|
|
const __be32 **usm,
|
|
|
|
void *data)
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
{
|
2017-12-02 00:47:21 +08:00
|
|
|
unsigned int ranges, is_kexec_kdump = 0;
|
|
|
|
unsigned long base, size, sz;
|
2008-07-03 11:35:54 +08:00
|
|
|
int nid;
|
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
/*
|
|
|
|
* Skip this block if the reserved bit is set in flags (0x80)
|
|
|
|
* or if the block is not assigned to this partition (0x8)
|
|
|
|
*/
|
|
|
|
if ((lmb->flags & DRCONF_MEM_RESERVED)
|
|
|
|
|| !(lmb->flags & DRCONF_MEM_ASSIGNED))
|
2020-07-29 19:40:32 +08:00
|
|
|
return 0;
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
if (*usm)
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
is_kexec_kdump = 1;
|
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
base = lmb->base_addr;
|
|
|
|
size = drmem_lmb_size();
|
|
|
|
ranges = 1;
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
if (is_kexec_kdump) {
|
|
|
|
ranges = read_usm_ranges(usm);
|
|
|
|
if (!ranges) /* there are no (base, size) duple */
|
2020-07-29 19:40:32 +08:00
|
|
|
return 0;
|
2017-12-02 00:47:21 +08:00
|
|
|
}
|
2008-07-03 11:35:54 +08:00
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
do {
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
if (is_kexec_kdump) {
|
2017-12-02 00:47:21 +08:00
|
|
|
base = read_n_cells(n_mem_addr_cells, usm);
|
|
|
|
size = read_n_cells(n_mem_size_cells, usm);
|
powerpc: Add support for dynamic reconfiguration memory in kexec/kdump kernels
Kdump kernel needs to use only those memory regions that it is allowed
to use (crashkernel, rtas, tce, etc.). Each of these regions have
their own sizes and are currently added under 'linux,usable-memory'
property under each memory@xxx node of the device tree.
The ibm,dynamic-memory property of ibm,dynamic-reconfiguration-memory
node (on POWER6) now stores in it the representation for most of the
logical memory blocks with the size of each memory block being a
constant (lmb_size). If one or more or part of the above mentioned
regions lie under one of the lmb from ibm,dynamic-memory property,
there is a need to identify those regions within the given lmb.
This makes the kernel recognize a new 'linux,drconf-usable-memory'
property added by kexec-tools. Each entry in this property is of the
form of a count followed by that many (base, size) pairs for the above
mentioned regions. The number of cells in the count value is given by
the #size-cells property of the root node.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-29 22:28:16 +08:00
|
|
|
}
|
2017-12-02 00:47:21 +08:00
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
nid = get_nid_and_numa_distance(lmb);
|
2017-12-02 00:47:21 +08:00
|
|
|
fake_numa_create_new_node(((base + size) >> PAGE_SHIFT),
|
|
|
|
&nid);
|
|
|
|
node_set_online(nid);
|
|
|
|
sz = numa_enforce_memory_limit(base, size);
|
|
|
|
if (sz)
|
|
|
|
memblock_set_node(base, sz, &memblock.memory, nid);
|
|
|
|
} while (--ranges);
|
2020-07-29 19:40:32 +08:00
|
|
|
|
|
|
|
return 0;
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int __init parse_numa_properties(void)
|
|
|
|
{
|
2011-08-11 04:44:22 +08:00
|
|
|
struct device_node *memory;
|
2006-03-21 08:36:45 +08:00
|
|
|
int default_nid = 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long i;
|
2021-08-12 21:22:21 +08:00
|
|
|
const __be32 *associativity;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (numa_enabled == 0) {
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_warn("disabled by user\n");
|
2005-04-17 06:20:36 +08:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
primary_domain_index = find_primary_domain_index();
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
if (primary_domain_index < 0) {
|
2019-07-01 22:36:26 +08:00
|
|
|
/*
|
2021-08-12 21:22:19 +08:00
|
|
|
* if we fail to parse primary_domain_index from device tree
|
2019-07-01 22:36:26 +08:00
|
|
|
* mark the numa disabled, boot with numa disabled.
|
|
|
|
*/
|
|
|
|
numa_enabled = false;
|
2021-08-12 21:22:19 +08:00
|
|
|
return primary_domain_index;
|
2019-07-01 22:36:26 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_debug("associativity depth for CPU/Memory: %d\n", primary_domain_index);
|
2006-03-21 08:34:45 +08:00
|
|
|
|
2021-08-12 21:22:23 +08:00
|
|
|
/*
|
|
|
|
* If it is FORM2 initialize the distance table here.
|
|
|
|
*/
|
|
|
|
if (affinity_form == FORM2_AFFINITY)
|
|
|
|
initialize_form2_numa_distance_lookup_table();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2006-03-21 08:36:45 +08:00
|
|
|
* Even though we connect cpus to numa domains later in SMP
|
|
|
|
* init, we need to know the node ids now. This is because
|
|
|
|
* each node to be onlined must have NODE_DATA etc backing it.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2006-03-21 08:36:45 +08:00
|
|
|
for_each_present_cpu(i) {
|
2021-08-12 21:22:21 +08:00
|
|
|
__be32 vphn_assoc[VPHN_ASSOC_BUFSIZE];
|
2011-08-11 04:44:23 +08:00
|
|
|
struct device_node *cpu;
|
2021-08-12 21:22:21 +08:00
|
|
|
int nid = NUMA_NO_NODE;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-12 21:22:21 +08:00
|
|
|
memset(vphn_assoc, 0, VPHN_ASSOC_BUFSIZE * sizeof(__be32));
|
|
|
|
|
|
|
|
if (__vphn_get_associativity(i, vphn_assoc) == 0) {
|
|
|
|
nid = associativity_to_nid(vphn_assoc);
|
|
|
|
initialize_form1_numa_distance(vphn_assoc);
|
|
|
|
} else {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't fall back to default_nid yet -- we will plug
|
|
|
|
* cpus into nodes once the memory scan has discovered
|
|
|
|
* the topology.
|
|
|
|
*/
|
2020-08-18 16:11:03 +08:00
|
|
|
cpu = of_get_cpu_node(i, NULL);
|
|
|
|
BUG_ON(!cpu);
|
2021-08-12 21:22:21 +08:00
|
|
|
|
|
|
|
associativity = of_get_associativity(cpu);
|
|
|
|
if (associativity) {
|
|
|
|
nid = associativity_to_nid(associativity);
|
|
|
|
initialize_form1_numa_distance(associativity);
|
|
|
|
}
|
2020-08-18 16:11:03 +08:00
|
|
|
of_node_put(cpu);
|
|
|
|
}
|
|
|
|
|
2020-11-27 13:37:38 +08:00
|
|
|
node_set_online(nid);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-12-06 04:06:42 +08:00
|
|
|
get_n_mem_cells(&n_mem_addr_cells, &n_mem_size_cells);
|
2011-08-11 04:44:22 +08:00
|
|
|
|
|
|
|
for_each_node_by_type(memory, "memory") {
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned long start;
|
|
|
|
unsigned long size;
|
2006-03-21 08:35:45 +08:00
|
|
|
int nid;
|
2005-04-17 06:20:36 +08:00
|
|
|
int ranges;
|
2013-08-07 00:01:44 +08:00
|
|
|
const __be32 *memcell_buf;
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned int len;
|
|
|
|
|
2007-04-03 20:26:41 +08:00
|
|
|
memcell_buf = of_get_property(memory,
|
2005-12-04 15:39:55 +08:00
|
|
|
"linux,usable-memory", &len);
|
|
|
|
if (!memcell_buf || len <= 0)
|
2007-04-03 20:26:41 +08:00
|
|
|
memcell_buf = of_get_property(memory, "reg", &len);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!memcell_buf || len <= 0)
|
|
|
|
continue;
|
|
|
|
|
2005-12-13 15:01:21 +08:00
|
|
|
/* ranges in cell */
|
|
|
|
ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
|
2005-04-17 06:20:36 +08:00
|
|
|
new_range:
|
|
|
|
/* these are order-sensitive, and modify the buffer pointer */
|
2005-12-06 04:06:42 +08:00
|
|
|
start = read_n_cells(n_mem_addr_cells, &memcell_buf);
|
|
|
|
size = read_n_cells(n_mem_size_cells, &memcell_buf);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-03-21 08:36:45 +08:00
|
|
|
/*
|
|
|
|
* Assumption: either all memory nodes or none will
|
|
|
|
* have associativity properties. If none, then
|
|
|
|
* everything goes to default_nid.
|
|
|
|
*/
|
2021-08-12 21:22:21 +08:00
|
|
|
associativity = of_get_associativity(memory);
|
|
|
|
if (associativity) {
|
|
|
|
nid = associativity_to_nid(associativity);
|
|
|
|
initialize_form1_numa_distance(associativity);
|
|
|
|
} else
|
2006-03-21 08:36:45 +08:00
|
|
|
nid = default_nid;
|
2008-02-01 12:57:31 +08:00
|
|
|
|
|
|
|
fake_numa_create_new_node(((start + size) >> PAGE_SHIFT), &nid);
|
2006-03-21 08:36:45 +08:00
|
|
|
node_set_online(nid);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-10-14 02:45:30 +08:00
|
|
|
size = numa_enforce_memory_limit(start, size);
|
|
|
|
if (size)
|
|
|
|
memblock_set_node(start, size, &memblock.memory, nid);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (--ranges)
|
|
|
|
goto new_range;
|
|
|
|
}
|
|
|
|
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
/*
|
2011-08-11 04:44:23 +08:00
|
|
|
* Now do the same thing for each MEMBLOCK listed in the
|
|
|
|
* ibm,dynamic-memory property in the
|
|
|
|
* ibm,dynamic-reconfiguration-memory node.
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
*/
|
|
|
|
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
|
2017-12-02 00:47:21 +08:00
|
|
|
if (memory) {
|
2020-07-29 19:40:32 +08:00
|
|
|
walk_drmem_lmbs(memory, NULL, numa_setup_drmem_lmb);
|
2017-12-02 00:47:21 +08:00
|
|
|
of_node_put(memory);
|
|
|
|
}
|
[POWERPC] Support ibm,dynamic-reconfiguration-memory nodes
For PAPR partitions with large amounts of memory, the firmware has an
alternative, more compact representation for the information about the
memory in the partition and its NUMA associativity information. This
adds the code to the kernel to parse this alternative representation.
The other part of this patch is telling the firmware that we can
handle the alternative representation. There is however a subtlety
here, because the firmware will invoke a reboot if the memory
representation we request is different from the representation that
firmware is currently using. This is because firmware can't change
the representation on the fly. Further, some firmware versions used
on POWER5+ machines have a bug where this reboot leaves the machine
with an altered value of load-base, which will prevent any kernel
booting until it is reset to the normal value (0x4000). Because of
this bug, we do NOT set fake_elf.rpanote.new_mem_def = 1, and thus we
do not request the new representation on POWER5+ and earlier machines.
We do request the new representation on POWER6, which uses the
ibm,client-architecture-support call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-29 19:27:42 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init setup_nonnuma(void)
|
|
|
|
{
|
2010-07-12 12:36:09 +08:00
|
|
|
unsigned long top_of_ram = memblock_end_of_DRAM();
|
|
|
|
unsigned long total_ram = memblock_phys_mem_size();
|
2006-09-27 16:49:49 +08:00
|
|
|
unsigned long start_pfn, end_pfn;
|
2010-08-04 11:43:53 +08:00
|
|
|
unsigned int nid = 0;
|
2020-10-14 07:58:03 +08:00
|
|
|
int i;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-08-26 18:05:18 +08:00
|
|
|
pr_debug("Top of RAM: 0x%lx, Total RAM: 0x%lx\n", top_of_ram, total_ram);
|
|
|
|
pr_debug("Memory hole size: %ldMB\n", (top_of_ram - total_ram) >> 20);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2020-10-14 07:58:03 +08:00
|
|
|
for_each_mem_pfn_range(i, MAX_NUMNODES, &start_pfn, &end_pfn, NULL) {
|
2008-02-01 12:57:31 +08:00
|
|
|
fake_numa_create_new_node(end_pfn, &nid);
|
2011-12-09 02:22:08 +08:00
|
|
|
memblock_set_node(PFN_PHYS(start_pfn),
|
2014-01-22 07:49:26 +08:00
|
|
|
PFN_PHYS(end_pfn - start_pfn),
|
|
|
|
&memblock.memory, nid);
|
2008-02-01 12:57:31 +08:00
|
|
|
node_set_online(nid);
|
2006-09-27 16:49:49 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2005-12-13 03:56:47 +08:00
|
|
|
void __init dump_numa_cpu_topology(void)
|
|
|
|
{
|
|
|
|
unsigned int node;
|
|
|
|
unsigned int cpu, count;
|
|
|
|
|
2019-07-01 22:36:26 +08:00
|
|
|
if (!numa_enabled)
|
2005-12-13 03:56:47 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
for_each_online_node(node) {
|
2016-10-18 16:52:14 +08:00
|
|
|
pr_info("Node %d CPUs:", node);
|
2005-12-13 03:56:47 +08:00
|
|
|
|
|
|
|
count = 0;
|
|
|
|
/*
|
|
|
|
* If we used a CPU iterator here we would miss printing
|
|
|
|
* the holes in the cpumap.
|
|
|
|
*/
|
2010-04-26 23:32:43 +08:00
|
|
|
for (cpu = 0; cpu < nr_cpu_ids; cpu++) {
|
|
|
|
if (cpumask_test_cpu(cpu,
|
|
|
|
node_to_cpumask_map[node])) {
|
2005-12-13 03:56:47 +08:00
|
|
|
if (count == 0)
|
2016-10-18 16:52:14 +08:00
|
|
|
pr_cont(" %u", cpu);
|
2005-12-13 03:56:47 +08:00
|
|
|
++count;
|
|
|
|
} else {
|
|
|
|
if (count > 1)
|
2016-10-18 16:52:14 +08:00
|
|
|
pr_cont("-%u", cpu - 1);
|
2005-12-13 03:56:47 +08:00
|
|
|
count = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (count > 1)
|
2016-10-18 16:52:14 +08:00
|
|
|
pr_cont("-%u", nr_cpu_ids - 1);
|
|
|
|
pr_cont("\n");
|
2005-12-13 03:56:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-17 20:15:33 +08:00
|
|
|
/* Initialize NODE_DATA for a node on the local memory */
|
|
|
|
static void __init setup_node_data(int nid, u64 start_pfn, u64 end_pfn)
|
2008-11-24 20:02:35 +08:00
|
|
|
{
|
2014-09-17 20:15:33 +08:00
|
|
|
u64 spanned_pages = end_pfn - start_pfn;
|
|
|
|
const size_t nd_size = roundup(sizeof(pg_data_t), SMP_CACHE_BYTES);
|
|
|
|
u64 nd_pa;
|
|
|
|
void *nd;
|
|
|
|
int tnid;
|
2008-11-24 20:02:35 +08:00
|
|
|
|
memblock: rename memblock_alloc{_nid,_try_nid} to memblock_phys_alloc*
Make it explicit that the caller gets a physical address rather than a
virtual one.
This will also allow using meblock_alloc prefix for memblock allocations
returning virtual address, which is done in the following patches.
The conversion is done using the following semantic patch:
@@
expression e1, e2, e3;
@@
(
- memblock_alloc(e1, e2)
+ memblock_phys_alloc(e1, e2)
|
- memblock_alloc_nid(e1, e2, e3)
+ memblock_phys_alloc_nid(e1, e2, e3)
|
- memblock_alloc_try_nid(e1, e2, e3)
+ memblock_phys_alloc_try_nid(e1, e2, e3)
)
Link: http://lkml.kernel.org/r/1536927045-23536-7-git-send-email-rppt@linux.vnet.ibm.com
Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chris Zankel <chris@zankel.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guan Xuetao <gxt@pku.edu.cn>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Jonas Bonn <jonas@southpole.se>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Palmer Dabbelt <palmer@sifive.com>
Cc: Paul Burton <paul.burton@mips.com>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Rich Felker <dalias@libc.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Serge Semin <fancer.lancer@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-10-31 06:07:59 +08:00
|
|
|
nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
|
2019-03-12 14:29:21 +08:00
|
|
|
if (!nd_pa)
|
|
|
|
panic("Cannot allocate %zu bytes for node %d data\n",
|
|
|
|
nd_size, nid);
|
|
|
|
|
2014-09-17 20:15:33 +08:00
|
|
|
nd = __va(nd_pa);
|
2008-11-24 20:02:35 +08:00
|
|
|
|
2014-09-17 20:15:33 +08:00
|
|
|
/* report and initialize */
|
|
|
|
pr_info(" NODE_DATA [mem %#010Lx-%#010Lx]\n",
|
|
|
|
nd_pa, nd_pa + nd_size - 1);
|
|
|
|
tnid = early_pfn_to_nid(nd_pa >> PAGE_SHIFT);
|
|
|
|
if (tnid != nid)
|
|
|
|
pr_info(" NODE_DATA(%d) on node %d\n", nid, tnid);
|
2008-11-24 20:02:35 +08:00
|
|
|
|
2014-09-17 20:15:33 +08:00
|
|
|
node_data[nid] = nd;
|
|
|
|
memset(NODE_DATA(nid), 0, sizeof(pg_data_t));
|
|
|
|
NODE_DATA(nid)->node_id = nid;
|
|
|
|
NODE_DATA(nid)->node_start_pfn = start_pfn;
|
|
|
|
NODE_DATA(nid)->node_spanned_pages = spanned_pages;
|
|
|
|
}
|
2008-11-24 20:02:35 +08:00
|
|
|
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
static void __init find_possible_nodes(void)
|
|
|
|
{
|
|
|
|
struct device_node *rtas;
|
powerpc/numa: Consider the max NUMA node for migratable LPAR
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead of the number of NUMA nodes from the actual system.
The DT property 'ibm,current-associativity-domains' defines the maximum
number of nodes the LPAR can see when running on that box. But if the
LPAR is being migrated on another box, it may see up to the nodes
defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable,
that value should be used.
Unfortunately, there is no easy way to know if an LPAR is migratable or
not. The hypervisor exports the property 'ibm,migratable-partition' in
the case it set to migrate partition, but that would not mean that the
current partition is migratable.
Without this patch, when a LPAR is started on a 2 node box and then
migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on
the 3rd node. In that case if a CPU from that 3rd node is added to the
LPAR, it will be wrongly assigned to the node because the kernel has
been set to use up to 2 nodes (the configuration of the departure node).
With this patch applies, the CPU is correctly added to the 3rd node.
Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup")
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com
2021-05-11 15:31:36 +08:00
|
|
|
const __be32 *domains = NULL;
|
2020-08-10 15:18:31 +08:00
|
|
|
int prop_length, max_nodes;
|
|
|
|
u32 i;
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
|
2019-07-01 22:36:26 +08:00
|
|
|
if (!numa_enabled)
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
rtas = of_find_node_by_path("/rtas");
|
|
|
|
if (!rtas)
|
|
|
|
return;
|
|
|
|
|
2020-08-10 15:18:31 +08:00
|
|
|
/*
|
|
|
|
* ibm,current-associativity-domains is a fairly recent property. If
|
|
|
|
* it doesn't exist, then fallback on ibm,max-associativity-domains.
|
|
|
|
* Current denotes what the platform can support compared to max
|
|
|
|
* which denotes what the Hypervisor can support.
|
powerpc/numa: Consider the max NUMA node for migratable LPAR
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead of the number of NUMA nodes from the actual system.
The DT property 'ibm,current-associativity-domains' defines the maximum
number of nodes the LPAR can see when running on that box. But if the
LPAR is being migrated on another box, it may see up to the nodes
defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable,
that value should be used.
Unfortunately, there is no easy way to know if an LPAR is migratable or
not. The hypervisor exports the property 'ibm,migratable-partition' in
the case it set to migrate partition, but that would not mean that the
current partition is migratable.
Without this patch, when a LPAR is started on a 2 node box and then
migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on
the 3rd node. In that case if a CPU from that 3rd node is added to the
LPAR, it will be wrongly assigned to the node because the kernel has
been set to use up to 2 nodes (the configuration of the departure node).
With this patch applies, the CPU is correctly added to the 3rd node.
Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup")
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com
2021-05-11 15:31:36 +08:00
|
|
|
*
|
|
|
|
* If the LPAR is migratable, new nodes might be activated after a LPM,
|
|
|
|
* so we should consider the max number in that case.
|
2020-08-10 15:18:31 +08:00
|
|
|
*/
|
powerpc/numa: Consider the max NUMA node for migratable LPAR
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead of the number of NUMA nodes from the actual system.
The DT property 'ibm,current-associativity-domains' defines the maximum
number of nodes the LPAR can see when running on that box. But if the
LPAR is being migrated on another box, it may see up to the nodes
defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable,
that value should be used.
Unfortunately, there is no easy way to know if an LPAR is migratable or
not. The hypervisor exports the property 'ibm,migratable-partition' in
the case it set to migrate partition, but that would not mean that the
current partition is migratable.
Without this patch, when a LPAR is started on a 2 node box and then
migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on
the 3rd node. In that case if a CPU from that 3rd node is added to the
LPAR, it will be wrongly assigned to the node because the kernel has
been set to use up to 2 nodes (the configuration of the departure node).
With this patch applies, the CPU is correctly added to the 3rd node.
Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup")
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com
2021-05-11 15:31:36 +08:00
|
|
|
if (!of_get_property(of_root, "ibm,migratable-partition", NULL))
|
|
|
|
domains = of_get_property(rtas,
|
|
|
|
"ibm,current-associativity-domains",
|
|
|
|
&prop_length);
|
2020-08-10 15:18:31 +08:00
|
|
|
if (!domains) {
|
|
|
|
domains = of_get_property(rtas, "ibm,max-associativity-domains",
|
|
|
|
&prop_length);
|
|
|
|
if (!domains)
|
powerpc/numa: Restrict possible nodes based on platform
As per draft LoPAPR (Revision 2.9_pre7), section B.5.3 "Run Time
Abstraction Services (RTAS) Node" available at:
https://openpowerfoundation.org/wp-content/uploads/2020/07/LoPAR-20200611.pdf
... there are 2 device tree properties:
"ibm,max-associativity-domains"
which defines the maximum number of domains that the firmware i.e
PowerVM can support.
and:
"ibm,current-associativity-domains"
which defines the maximum number of domains that the current
platform can support.
The value of "ibm,max-associativity-domains" is always greater than or
equal to "ibm,current-associativity-domains" property. If the latter
property is not available, use "ibm,max-associativity-domain" as a
fallback. In this yet to be released LoPAPR, "ibm,current-associativity-domains"
is mentioned in page 833 / B.5.3 which is covered under under
"Appendix B. System Binding" section
Currently powerpc uses the "ibm,max-associativity-domains" property
while setting the possible number of nodes. This is currently set at
32. However the possible number of nodes for a platform may be
significantly less. Hence set the possible number of nodes based on
"ibm,current-associativity-domains" property.
Nathan Lynch had raised a valid concern that post LPM (Live Partition
Migration), a user could DLPAR add processors and memory after LPM
with "new" associativity properties:
https://lore.kernel.org/linuxppc-dev/871rljfet9.fsf@linux.ibm.com/t/#u
He also pointed out that "ibm,max-associativity-domains" has the same
contents on all currently available PowerVM systems, unlike
"ibm,current-associativity-domains" and hence may be better able to
handle the new NUMA associativity properties.
However with the recent commit dbce45628085 ("powerpc/numa: Limit
possible nodes to within num_possible_nodes"), all new NUMA
associativity properties are capped to initially set nr_node_ids.
Hence this commit should be safe with any new DLPAR add post LPM.
$ lsprop /proc/device-tree/rtas/ibm,*associ*-domains
/proc/device-tree/rtas/ibm,current-associativity-domains
00000005 00000001 00000002 00000002 00000002 00000010
/proc/device-tree/rtas/ibm,max-associativity-domains
00000005 00000001 00000008 00000020 00000020 00000100
$ cat /sys/devices/system/node/possible ##Before patch
0-31
$ cat /sys/devices/system/node/possible ##After patch
0-1
Note the maximum nodes this platform can support is only 2 but the
possible nodes is set to 32.
This is important because lot of kernel and user space code allocate
structures for all possible nodes leading to a lot of memory that is
allocated but not used.
I ran a simple experiment to create and destroy 100 memory cgroups on
boot on a 8 node machine (Power8 Alpine).
Before patch:
free -k at boot
total used free shared buff/cache available
Mem: 523498176 4106816 518820608 22272 570752 516606720
Swap: 4194240 0 4194240
free -k after creating 100 memory cgroups
total used free shared buff/cache available
Mem: 523498176 4628416 518246464 22336 623296 516058688
Swap: 4194240 0 4194240
free -k after destroying 100 memory cgroups
total used free shared buff/cache available
Mem: 523498176 4697408 518173760 22400 627008 515987904
Swap: 4194240 0 4194240
After patch:
free -k at boot
total used free shared buff/cache available
Mem: 523498176 3969472 518933888 22272 594816 516731776
Swap: 4194240 0 4194240
free -k after creating 100 memory cgroups
total used free shared buff/cache available
Mem: 523498176 4181888 518676096 22208 640192 516496448
Swap: 4194240 0 4194240
free -k after destroying 100 memory cgroups
total used free shared buff/cache available
Mem: 523498176 4232320 518619904 22272 645952 516443264
Swap: 4194240 0 4194240
Observations:
Fixed kernel takes 137344 kb (4106816-3969472) less to boot.
Fixed kernel takes 309184 kb (4628416-4181888-137344) less to create 100 memcgs.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
[mpe: Reformat change log a bit for readability]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200817055257.110873-1-srikar@linux.vnet.ibm.com
2020-08-17 13:52:57 +08:00
|
|
|
goto out;
|
|
|
|
}
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
|
2021-08-12 21:22:19 +08:00
|
|
|
max_nodes = of_read_number(&domains[primary_domain_index], 1);
|
powerpc/numa: Consider the max NUMA node for migratable LPAR
When a LPAR is migratable, we should consider the maximum possible NUMA
node instead of the number of NUMA nodes from the actual system.
The DT property 'ibm,current-associativity-domains' defines the maximum
number of nodes the LPAR can see when running on that box. But if the
LPAR is being migrated on another box, it may see up to the nodes
defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable,
that value should be used.
Unfortunately, there is no easy way to know if an LPAR is migratable or
not. The hypervisor exports the property 'ibm,migratable-partition' in
the case it set to migrate partition, but that would not mean that the
current partition is migratable.
Without this patch, when a LPAR is started on a 2 node box and then
migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on
the 3rd node. In that case if a CPU from that 3rd node is added to the
LPAR, it will be wrongly assigned to the node because the kernel has
been set to use up to 2 nodes (the configuration of the departure node).
With this patch applies, the CPU is correctly added to the 3rd node.
Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup")
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
Reviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com
2021-05-11 15:31:36 +08:00
|
|
|
pr_info("Partition configured for %d NUMA nodes.\n", max_nodes);
|
|
|
|
|
2020-08-10 15:18:31 +08:00
|
|
|
for (i = 0; i < max_nodes; i++) {
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
if (!node_possible(i))
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
node_set(i, node_possible_map);
|
|
|
|
}
|
|
|
|
|
2020-08-10 15:18:31 +08:00
|
|
|
prop_length /= sizeof(int);
|
2021-08-12 21:22:19 +08:00
|
|
|
if (prop_length > primary_domain_index + 2)
|
2020-08-10 15:18:31 +08:00
|
|
|
coregroup_enabled = 1;
|
|
|
|
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
out:
|
|
|
|
of_node_put(rtas);
|
|
|
|
}
|
|
|
|
|
2018-02-13 23:08:16 +08:00
|
|
|
void __init mem_topology_setup(void)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2018-02-13 23:08:16 +08:00
|
|
|
int cpu;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
powerpc/numa: Offline memoryless cpuless node 0
Currently Linux kernel with CONFIG_NUMA on a system with multiple
possible nodes, marks node 0 as online at boot. However in practice,
there are systems which have node 0 as memoryless and cpuless.
This can cause numa_balancing to be enabled on systems with only one node
with memory and CPUs. The existence of this dummy node which is cpuless and
memoryless node can confuse users/scripts looking at output of lscpu /
numactl.
By marking, node 0 as offline, lets stop assuming that node 0 is
always online. If node 0 has CPU or memory that are online, node 0 will
again be set as online.
v5.8
available: 2 nodes (0,2)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 2 cpus: 0 1 2 3 4 5 6 7
node 2 size: 32625 MB
node 2 free: 31490 MB
node distances:
node 0 2
0: 10 20
2: 20 10
proc and sys files
------------------
/sys/devices/system/node/online: 0,2
/proc/sys/kernel/numa_balancing: 1
/sys/devices/system/node/has_cpu: 2
/sys/devices/system/node/has_memory: 2
/sys/devices/system/node/has_normal_memory: 2
/sys/devices/system/node/possible: 0-31
v5.8 + patch
------------------
available: 1 nodes (2)
node 2 cpus: 0 1 2 3 4 5 6 7
node 2 size: 32625 MB
node 2 free: 31487 MB
node distances:
node 2
2: 10
proc and sys files
------------------
/sys/devices/system/node/online: 2
/proc/sys/kernel/numa_balancing: 0
/sys/devices/system/node/has_cpu: 2
/sys/devices/system/node/has_memory: 2
/sys/devices/system/node/has_normal_memory: 2
/sys/devices/system/node/possible: 0-31
Example of a node with online CPUs/memory on node 0.
(Same o/p with and without patch)
numactl -H
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
node 0 size: 32482 MB
node 0 free: 22994 MB
node 1 cpus: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95
node 1 size: 0 MB
node 1 free: 0 MB
node 2 cpus: 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143
node 2 size: 0 MB
node 2 free: 0 MB
node 3 cpus: 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 node 3 size: 0 MB
node 3 free: 0 MB
node distances:
node 0 1 2 3
0: 10 20 40 40
1: 20 10 40 40
2: 40 40 10 20
3: 40 40 20 10
Note: On Powerpc, cpu_to_node of possible but not present cpus would
previously return 0. Hence this commit depends on commit ("powerpc/numa: Set
numa_node for all possible cpus") and commit ("powerpc/numa: Prefer node id
queried from vphn"). Without the 2 commits, Powerpc system might crash.
1. User space applications like Numactl, lscpu, that parse the sysfs tend to
believe there is an extra online node. This tends to confuse users and
applications. Other user space applications start believing that system was
not able to use all the resources (i.e missing resources) or the system was
not setup correctly.
2. Also existence of dummy node also leads to inconsistent information. The
number of online nodes is inconsistent with the information in the
device-tree and resource-dump
3. When the dummy node is present, single node non-Numa systems end up showing
up as NUMA systems and numa_balancing gets enabled. This will mean we take
the hit from the unnecessary numa hinting faults.
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200818081104.57888-4-srikar@linux.vnet.ibm.com
2020-08-18 16:11:04 +08:00
|
|
|
/*
|
|
|
|
* Linux/mm assumes node 0 to be online at boot. However this is not
|
|
|
|
* true on PowerPC, where node 0 is similar to any other node, it
|
|
|
|
* could be cpuless, memoryless node. So force node 0 to be offline
|
|
|
|
* for now. This will prevent cpuless, memoryless node 0 showing up
|
|
|
|
* unnecessarily as online. If a node has cpus or memory that need
|
|
|
|
* to be online, then node will anyway be marked online.
|
|
|
|
*/
|
|
|
|
node_set_offline(0);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (parse_numa_properties())
|
|
|
|
setup_nonnuma();
|
|
|
|
|
powerpc/numa: Reset node_possible_map to only node_online_map
Raghu noticed an issue with excessive memory allocation on power with a
simple cgroup test, specifically, in mem_cgroup_css_alloc ->
for_each_node -> alloc_mem_cgroup_per_zone_info(), which ends up blowing
up the kmalloc-2048 slab (to the order of 200MB for 400 cgroup
directories).
The underlying issue is that NODES_SHIFT on power is 8 (256 NUMA nodes
possible), which defines node_possible_map, which in turn defines the
value of nr_node_ids in setup_nr_node_ids and the iteration of
for_each_node.
In practice, we never see a system with 256 NUMA nodes, and in fact, we
do not support node hotplug on power in the first place, so the nodes
that are online when we come up are the nodes that will be present for
the lifetime of this kernel. So let's, at least, drop the NUMA possible
map down to the online map at runtime. This is similar to what x86 does
in its initialization routines.
mem_cgroup_css_alloc should also be fixed to only iterate over
memory-populated nodes and handle hotplug, but that is a separate
change.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-11 07:50:59 +08:00
|
|
|
/*
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
* Modify the set of possible NUMA nodes to reflect information
|
|
|
|
* available about the set of online nodes, and the set of nodes
|
|
|
|
* that we expect to make use of for this platform's affinity
|
|
|
|
* calculations.
|
powerpc/numa: Reset node_possible_map to only node_online_map
Raghu noticed an issue with excessive memory allocation on power with a
simple cgroup test, specifically, in mem_cgroup_css_alloc ->
for_each_node -> alloc_mem_cgroup_per_zone_info(), which ends up blowing
up the kmalloc-2048 slab (to the order of 200MB for 400 cgroup
directories).
The underlying issue is that NODES_SHIFT on power is 8 (256 NUMA nodes
possible), which defines node_possible_map, which in turn defines the
value of nr_node_ids in setup_nr_node_ids and the iteration of
for_each_node.
In practice, we never see a system with 256 NUMA nodes, and in fact, we
do not support node hotplug on power in the first place, so the nodes
that are online when we come up are the nodes that will be present for
the lifetime of this kernel. So let's, at least, drop the NUMA possible
map down to the online map at runtime. This is similar to what x86 does
in its initialization routines.
mem_cgroup_css_alloc should also be fixed to only iterate over
memory-populated nodes and handle hotplug, but that is a separate
change.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-03-11 07:50:59 +08:00
|
|
|
*/
|
|
|
|
nodes_and(node_possible_map, node_possible_map, node_online_map);
|
|
|
|
|
powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes
On powerpc systems which allow 'hot-add' of CPU or memory resources,
it may occur that the new resources are to be inserted into nodes that
were not used for these resources at bootup. In the kernel, any node
that is used must be defined and initialized. These empty nodes may
occur when,
* Dedicated vs. shared resources. Shared resources require information
such as the VPHN hcall for CPU assignment to nodes. Associativity
decisions made based on dedicated resource rules, such as
associativity properties in the device tree, may vary from decisions
made using the values returned by the VPHN hcall.
* memoryless nodes at boot. Nodes need to be defined as 'possible' at
boot for operation with other code modules. Previously, the powerpc
code would limit the set of possible nodes to those which have
memory assigned at boot, and were thus online. Subsequent add/remove
of CPUs or memory would only work with this subset of possible
nodes.
* memoryless nodes with CPUs at boot. Due to the previous restriction
on nodes, nodes that had CPUs but no memory were being collapsed
into other nodes that did have memory at boot. In practice this
meant that the node assignment presented by the runtime kernel
differed from the affinity and associativity attributes presented by
the device tree or VPHN hcalls. Nodes that might be known to the
pHyp were not 'possible' in the runtime kernel because they did not
have memory at boot.
This patch ensures that sufficient nodes are defined to support
configuration requirements after boot, as well as at boot. This patch
set fixes a couple of problems.
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node. * Nodes which have no
resources assigned at boot, but which may still be referenced
subsequently by affinity or associativity attributes, are kept in
the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs
to the system can reference these nodes and bring them online
instead of redirecting to one of the set of nodes that were known to
have memory at boot.
This patch extracts the value of the lowest domain level (number of
allocable resources) from the device tree property
"ibm,max-associativity-domains" to use as the maximum number of nodes
to setup as possibly available in the system. This new setting will
override the instruction:
nodes_and(node_possible_map, node_possible_map, node_online_map);
presently seen in the function arch/powerpc/mm/numa.c:initmem_init().
If the "ibm,max-associativity-domains" property is not present at
boot, no operation will be performed to define or enable additional
nodes, or enable the above 'nodes_and()'.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:36 +08:00
|
|
|
find_possible_nodes();
|
|
|
|
|
2018-02-13 23:08:16 +08:00
|
|
|
setup_node_to_cpumask_map();
|
|
|
|
|
|
|
|
reset_numa_cpu_lookup_table();
|
|
|
|
|
2020-08-18 16:11:02 +08:00
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
/*
|
|
|
|
* Powerpc with CONFIG_NUMA always used to have a node 0,
|
|
|
|
* even if it was memoryless or cpuless. For all cpus that
|
|
|
|
* are possible but not present, cpu_to_node() would point
|
|
|
|
* to node 0. To remove a cpuless, memoryless dummy node,
|
|
|
|
* powerpc need to make sure all possible but not present
|
|
|
|
* cpu_to_node are set to a proper node.
|
|
|
|
*/
|
2018-02-13 23:08:16 +08:00
|
|
|
numa_setup_cpu(cpu);
|
2020-08-18 16:11:02 +08:00
|
|
|
}
|
2018-02-13 23:08:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void __init initmem_init(void)
|
|
|
|
{
|
|
|
|
int nid;
|
|
|
|
|
|
|
|
max_low_pfn = memblock_end_of_DRAM() >> PAGE_SHIFT;
|
|
|
|
max_pfn = max_low_pfn;
|
|
|
|
|
|
|
|
memblock_dump_all();
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
for_each_online_node(nid) {
|
2006-09-27 16:49:49 +08:00
|
|
|
unsigned long start_pfn, end_pfn;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-09-27 16:49:49 +08:00
|
|
|
get_pfn_range_for_nid(nid, &start_pfn, &end_pfn);
|
2014-09-17 20:15:33 +08:00
|
|
|
setup_node_data(nid, start_pfn, end_pfn);
|
2008-11-24 20:02:35 +08:00
|
|
|
}
|
2009-06-03 05:16:38 +08:00
|
|
|
|
2014-09-17 20:15:36 +08:00
|
|
|
sparse_init();
|
2010-04-26 23:32:43 +08:00
|
|
|
|
powerpc: reorder per-cpu NUMA information's initialization
There is an issue currently where NUMA information is used on powerpc
(and possibly ia64) before it has been read from the device-tree, which
leads to large slab consumption with CONFIG_SLUB and memoryless nodes.
NUMA powerpc non-boot CPU's cpu_to_node/cpu_to_mem is only accurate
after start_secondary(), similar to ia64, which is invoked via
smp_init().
Commit 6ee0578b4daae ("workqueue: mark init_workqueues() as
early_initcall()") made init_workqueues() be invoked via
do_pre_smp_initcalls(), which is obviously before the secondary
processors are online.
Additionally, the following commits changed init_workqueues() to use
cpu_to_node to determine the node to use for kthread_create_on_node:
bce903809ab3f ("workqueue: add wq_numa_tbl_len and
wq_numa_possible_cpumask[]")
f3f90ad469342 ("workqueue: determine NUMA node of workers accourding to
the allowed cpumask")
Therefore, when init_workqueues() runs, it sees all CPUs as being on
Node 0. On LPARs or KVM guests where Node 0 is memoryless, this leads to
a high number of slab deactivations
(http://www.spinics.net/lists/linux-mm/msg67489.html).
Fix this by initializing the powerpc-specific CPU<->node/local memory
node mapping as early as possible, which on powerpc is
do_init_bootmem(). Currently that function initializes the mapping for
the boot CPU, but we extend it to setup the mapping for all possible
CPUs. Then, in smp_prepare_cpus(), we can correspondingly set the
per-cpu values for all possible CPUs. That ensures that before the
early_initcalls run (and really as early as possible), the per-cpu NUMA
mapping is accurate.
While testing memoryless nodes on PowerKVM guests with a fix to the
workqueue logic to use cpu_to_mem() instead of cpu_to_node(), with a
guest topology of:
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
node 1 size: 16336 MB
node 1 free: 15329 MB
node distances:
node 0 1
0: 10 40
1: 40 10
the slab consumption decreases from
Slab: 932416 kB
SUnreclaim: 902336 kB
to
Slab: 395264 kB
SUnreclaim: 359424 kB
And we a corresponding increase in the slab efficiency from
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 337 MB 11.28% 100.00%
task_struct 288 MB 9.93% 100.00%
to
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 37 MB 100.00% 100.00%
task_struct 31 MB 100.00% 100.00%
Powerpc didn't support memoryless nodes until recently (64bb80d87f01
"powerpc/numa: Enable CONFIG_HAVE_MEMORYLESS_NODES" and 8c272261194d
"powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID"). Those commits also
helped improve memory consumption with these kind of environments.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-07-18 07:15:12 +08:00
|
|
|
/*
|
|
|
|
* We need the numa_cpu_lookup_table to be accurate for all CPUs,
|
|
|
|
* even before we online them, so that we can use cpu_to_{node,mem}
|
|
|
|
* early in boot, cf. smp_prepare_cpus().
|
2016-07-18 22:07:28 +08:00
|
|
|
* _nocalls() + manual invocation is used because cpuhp is not yet
|
|
|
|
* initialized for the boot CPU.
|
powerpc: reorder per-cpu NUMA information's initialization
There is an issue currently where NUMA information is used on powerpc
(and possibly ia64) before it has been read from the device-tree, which
leads to large slab consumption with CONFIG_SLUB and memoryless nodes.
NUMA powerpc non-boot CPU's cpu_to_node/cpu_to_mem is only accurate
after start_secondary(), similar to ia64, which is invoked via
smp_init().
Commit 6ee0578b4daae ("workqueue: mark init_workqueues() as
early_initcall()") made init_workqueues() be invoked via
do_pre_smp_initcalls(), which is obviously before the secondary
processors are online.
Additionally, the following commits changed init_workqueues() to use
cpu_to_node to determine the node to use for kthread_create_on_node:
bce903809ab3f ("workqueue: add wq_numa_tbl_len and
wq_numa_possible_cpumask[]")
f3f90ad469342 ("workqueue: determine NUMA node of workers accourding to
the allowed cpumask")
Therefore, when init_workqueues() runs, it sees all CPUs as being on
Node 0. On LPARs or KVM guests where Node 0 is memoryless, this leads to
a high number of slab deactivations
(http://www.spinics.net/lists/linux-mm/msg67489.html).
Fix this by initializing the powerpc-specific CPU<->node/local memory
node mapping as early as possible, which on powerpc is
do_init_bootmem(). Currently that function initializes the mapping for
the boot CPU, but we extend it to setup the mapping for all possible
CPUs. Then, in smp_prepare_cpus(), we can correspondingly set the
per-cpu values for all possible CPUs. That ensures that before the
early_initcalls run (and really as early as possible), the per-cpu NUMA
mapping is accurate.
While testing memoryless nodes on PowerKVM guests with a fix to the
workqueue logic to use cpu_to_mem() instead of cpu_to_node(), with a
guest topology of:
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
node 1 size: 16336 MB
node 1 free: 15329 MB
node distances:
node 0 1
0: 10 40
1: 40 10
the slab consumption decreases from
Slab: 932416 kB
SUnreclaim: 902336 kB
to
Slab: 395264 kB
SUnreclaim: 359424 kB
And we a corresponding increase in the slab efficiency from
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 337 MB 11.28% 100.00%
task_struct 288 MB 9.93% 100.00%
to
slab mem objs slabs
used active active
------------------------------------------------------------
kmalloc-16384 37 MB 100.00% 100.00%
task_struct 31 MB 100.00% 100.00%
Powerpc didn't support memoryless nodes until recently (64bb80d87f01
"powerpc/numa: Enable CONFIG_HAVE_MEMORYLESS_NODES" and 8c272261194d
"powerpc/numa: Enable USE_PERCPU_NUMA_NODE_ID"). Those commits also
helped improve memory consumption with these kind of environments.
Signed-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-07-18 07:15:12 +08:00
|
|
|
*/
|
2016-12-22 03:19:54 +08:00
|
|
|
cpuhp_setup_state_nocalls(CPUHP_POWER_NUMA_PREPARE, "powerpc/numa:prepare",
|
2016-07-18 22:07:28 +08:00
|
|
|
ppc_numa_cpu_prepare, ppc_numa_cpu_dead);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int __init early_numa(char *p)
|
|
|
|
{
|
|
|
|
if (!p)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (strstr(p, "off"))
|
|
|
|
numa_enabled = 0;
|
|
|
|
|
2008-02-01 12:57:31 +08:00
|
|
|
p = strstr(p, "fake=");
|
|
|
|
if (p)
|
|
|
|
cmdline = p + strlen("fake=");
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
early_param("numa", early_numa);
|
2005-12-06 04:06:42 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_MEMORY_HOTPLUG
|
2008-07-03 11:25:08 +08:00
|
|
|
/*
|
2009-02-17 16:08:30 +08:00
|
|
|
* Find the node associated with a hot added memory section for
|
|
|
|
* memory represented in the device tree by the property
|
|
|
|
* ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory.
|
2008-07-03 11:25:08 +08:00
|
|
|
*/
|
2017-12-02 00:47:21 +08:00
|
|
|
static int hot_add_drconf_scn_to_nid(unsigned long scn_addr)
|
2008-07-03 11:25:08 +08:00
|
|
|
{
|
2017-12-02 00:47:21 +08:00
|
|
|
struct drmem_lmb *lmb;
|
2010-07-23 08:35:52 +08:00
|
|
|
unsigned long lmb_size;
|
2019-03-06 07:42:58 +08:00
|
|
|
int nid = NUMA_NO_NODE;
|
2008-07-03 11:25:08 +08:00
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
lmb_size = drmem_lmb_size();
|
2008-07-03 11:25:08 +08:00
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
for_each_drmem_lmb(lmb) {
|
2008-07-03 11:25:08 +08:00
|
|
|
/* skip this block if it is reserved or not assigned to
|
|
|
|
* this partition */
|
2017-12-02 00:47:21 +08:00
|
|
|
if ((lmb->flags & DRCONF_MEM_RESERVED)
|
|
|
|
|| !(lmb->flags & DRCONF_MEM_ASSIGNED))
|
2008-07-03 11:25:08 +08:00
|
|
|
continue;
|
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
if ((scn_addr < lmb->base_addr)
|
|
|
|
|| (scn_addr >= (lmb->base_addr + lmb_size)))
|
2009-02-17 16:08:30 +08:00
|
|
|
continue;
|
|
|
|
|
2017-12-02 00:47:21 +08:00
|
|
|
nid = of_drconf_to_nid_single(lmb);
|
2009-02-17 16:08:30 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the node associated with a hot added memory section for memory
|
|
|
|
* represented in the device tree as a node (i.e. memory@XXXX) for
|
2010-07-12 12:36:09 +08:00
|
|
|
* each memblock.
|
2009-02-17 16:08:30 +08:00
|
|
|
*/
|
2013-10-28 22:20:50 +08:00
|
|
|
static int hot_add_node_scn_to_nid(unsigned long scn_addr)
|
2009-02-17 16:08:30 +08:00
|
|
|
{
|
2011-08-11 04:44:22 +08:00
|
|
|
struct device_node *memory;
|
2019-03-06 07:42:58 +08:00
|
|
|
int nid = NUMA_NO_NODE;
|
2009-02-17 16:08:30 +08:00
|
|
|
|
2011-08-11 04:44:22 +08:00
|
|
|
for_each_node_by_type(memory, "memory") {
|
2009-02-17 16:08:30 +08:00
|
|
|
unsigned long start, size;
|
|
|
|
int ranges;
|
2013-08-07 00:01:44 +08:00
|
|
|
const __be32 *memcell_buf;
|
2009-02-17 16:08:30 +08:00
|
|
|
unsigned int len;
|
|
|
|
|
|
|
|
memcell_buf = of_get_property(memory, "reg", &len);
|
|
|
|
if (!memcell_buf || len <= 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* ranges in cell */
|
|
|
|
ranges = (len >> 2) / (n_mem_addr_cells + n_mem_size_cells);
|
|
|
|
|
|
|
|
while (ranges--) {
|
|
|
|
start = read_n_cells(n_mem_addr_cells, &memcell_buf);
|
|
|
|
size = read_n_cells(n_mem_size_cells, &memcell_buf);
|
|
|
|
|
|
|
|
if ((scn_addr < start) || (scn_addr >= (start + size)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
nid = of_node_to_nid_single(memory);
|
|
|
|
break;
|
|
|
|
}
|
2008-07-03 11:25:08 +08:00
|
|
|
|
2009-02-17 16:08:30 +08:00
|
|
|
if (nid >= 0)
|
|
|
|
break;
|
2008-07-03 11:25:08 +08:00
|
|
|
}
|
|
|
|
|
2011-08-11 04:44:21 +08:00
|
|
|
of_node_put(memory);
|
|
|
|
|
2009-02-17 16:08:30 +08:00
|
|
|
return nid;
|
2008-07-03 11:25:08 +08:00
|
|
|
}
|
|
|
|
|
2005-12-06 04:06:42 +08:00
|
|
|
/*
|
|
|
|
* Find the node associated with a hot added memory section. Section
|
2010-07-12 12:36:09 +08:00
|
|
|
* corresponds to a SPARSEMEM section, not an MEMBLOCK. It is assumed that
|
|
|
|
* sections are fully contained within a single MEMBLOCK.
|
2005-12-06 04:06:42 +08:00
|
|
|
*/
|
|
|
|
int hot_add_scn_to_nid(unsigned long scn_addr)
|
|
|
|
{
|
|
|
|
struct device_node *memory = NULL;
|
2016-12-13 08:42:52 +08:00
|
|
|
int nid;
|
2005-12-06 04:06:42 +08:00
|
|
|
|
2019-07-01 22:36:26 +08:00
|
|
|
if (!numa_enabled)
|
2010-03-06 05:42:43 +08:00
|
|
|
return first_online_node;
|
2008-07-03 11:25:08 +08:00
|
|
|
|
|
|
|
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
|
|
|
|
if (memory) {
|
2017-12-02 00:47:21 +08:00
|
|
|
nid = hot_add_drconf_scn_to_nid(scn_addr);
|
2008-07-03 11:25:08 +08:00
|
|
|
of_node_put(memory);
|
2009-02-17 16:08:30 +08:00
|
|
|
} else {
|
|
|
|
nid = hot_add_node_scn_to_nid(scn_addr);
|
2008-07-03 11:25:08 +08:00
|
|
|
}
|
2005-12-06 04:06:42 +08:00
|
|
|
|
2016-11-17 00:45:03 +08:00
|
|
|
if (nid < 0 || !node_possible(nid))
|
2010-03-06 05:42:43 +08:00
|
|
|
nid = first_online_node;
|
2005-12-06 04:06:42 +08:00
|
|
|
|
2009-02-17 16:08:30 +08:00
|
|
|
return nid;
|
2005-12-06 04:06:42 +08:00
|
|
|
}
|
2009-02-17 16:08:30 +08:00
|
|
|
|
2010-10-27 01:35:12 +08:00
|
|
|
static u64 hot_add_drconf_memory_max(void)
|
|
|
|
{
|
2016-05-12 21:34:14 +08:00
|
|
|
struct device_node *memory = NULL;
|
powerpc/numa: Fix multiple bugs in memory_hotplug_max()
memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:
1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
all the LMBs of the guest, but that is not true for PowerKVM which
populates only DR LMBs (LMBs that can be hotplugged/removed) in that
property.
2 hot_add_drconf_memory_max() multiplies lmb-size with lmb-count to arrive
at the max possible address. Since ibm,dynamic-memory doesn't include
RMA LMBs, the address thus obtained will be less than the actual max
address. For example, if max possible memory size is 32G, with lmb-size
of 256MB there can be 127 LMBs in ibm,dynamic-memory (1 LMB for RMA
which won't be present here). hot_add_drconf_memory_max() would then
return the max addressable memory as 127 * 256MB = 31.75GB, the max
address should have been 32G which is what ibm,lrdr-capacity shows.
3 In PowerKVM, there can be a gap between the end of boot time RAM and
beginning of hotplug RAM area. So just multiplying lmb-count with
lmb-size will not provide the correct max possible address for PowerKVM.
This patch fixes 1 by using ibm,lrdr-capacity property to return the max
addressable memory whenever the property is present. Then it fixes 2 & 3
by fetching the address of the last LMB in ibm,dynamic-memory property.
Fixes: cd34206e949b ("powerpc: Add memory_hotplug_max()")
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-05-12 21:34:15 +08:00
|
|
|
struct device_node *dn = NULL;
|
|
|
|
const __be64 *lrdr = NULL;
|
|
|
|
|
|
|
|
dn = of_find_node_by_path("/rtas");
|
|
|
|
if (dn) {
|
|
|
|
lrdr = of_get_property(dn, "ibm,lrdr-capacity", NULL);
|
|
|
|
of_node_put(dn);
|
|
|
|
if (lrdr)
|
|
|
|
return be64_to_cpup(lrdr);
|
|
|
|
}
|
2010-10-27 01:35:12 +08:00
|
|
|
|
2016-05-12 21:34:14 +08:00
|
|
|
memory = of_find_node_by_path("/ibm,dynamic-reconfiguration-memory");
|
|
|
|
if (memory) {
|
|
|
|
of_node_put(memory);
|
2017-12-02 00:47:21 +08:00
|
|
|
return drmem_lmb_memory_max();
|
2016-05-12 21:34:14 +08:00
|
|
|
}
|
powerpc/numa: Fix multiple bugs in memory_hotplug_max()
memory_hotplug_max() uses hot_add_drconf_memory_max() to get maxmimum
addressable memory by referring to ibm,dyanamic-memory property. There
are three problems with the current approach:
1 hot_add_drconf_memory_max() assumes that ibm,dynamic-memory includes
all the LMBs of the guest, but that is not true for PowerKVM which
populates only DR LMBs (LMBs that can be hotplugged/removed) in that
property.
2 hot_add_drconf_memory_max() multiplies lmb-size with lmb-count to arrive
at the max possible address. Since ibm,dynamic-memory doesn't include
RMA LMBs, the address thus obtained will be less than the actual max
address. For example, if max possible memory size is 32G, with lmb-size
of 256MB there can be 127 LMBs in ibm,dynamic-memory (1 LMB for RMA
which won't be present here). hot_add_drconf_memory_max() would then
return the max addressable memory as 127 * 256MB = 31.75GB, the max
address should have been 32G which is what ibm,lrdr-capacity shows.
3 In PowerKVM, there can be a gap between the end of boot time RAM and
beginning of hotplug RAM area. So just multiplying lmb-count with
lmb-size will not provide the correct max possible address for PowerKVM.
This patch fixes 1 by using ibm,lrdr-capacity property to return the max
addressable memory whenever the property is present. Then it fixes 2 & 3
by fetching the address of the last LMB in ibm,dynamic-memory property.
Fixes: cd34206e949b ("powerpc: Add memory_hotplug_max()")
Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2016-05-12 21:34:15 +08:00
|
|
|
return 0;
|
2010-10-27 01:35:12 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* memory_hotplug_max - return max address of memory that may be added
|
|
|
|
*
|
|
|
|
* This is currently only used on systems that support drconfig memory
|
|
|
|
* hotplug.
|
|
|
|
*/
|
|
|
|
u64 memory_hotplug_max(void)
|
|
|
|
{
|
|
|
|
return max(hot_add_drconf_memory_max(), memblock_end_of_DRAM());
|
|
|
|
}
|
2005-12-06 04:06:42 +08:00
|
|
|
#endif /* CONFIG_MEMORY_HOTPLUG */
|
2010-12-01 20:31:15 +08:00
|
|
|
|
2011-01-21 03:00:51 +08:00
|
|
|
/* Virtual Processor Home Node (VPHN) support */
|
2010-12-18 06:07:47 +08:00
|
|
|
#ifdef CONFIG_PPC_SPLPAR
|
2017-09-09 04:47:27 +08:00
|
|
|
static int topology_inited;
|
2010-12-01 20:31:15 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Retrieve the new associativity information for a virtual processor's
|
|
|
|
* home node.
|
|
|
|
*/
|
|
|
|
static long vphn_get_associativity(unsigned long cpu,
|
2013-08-07 00:01:44 +08:00
|
|
|
__be32 *associativity)
|
2010-12-01 20:31:15 +08:00
|
|
|
{
|
2011-01-21 03:01:35 +08:00
|
|
|
long rc;
|
2010-12-01 20:31:15 +08:00
|
|
|
|
2019-07-04 01:03:58 +08:00
|
|
|
rc = hcall_vphn(get_hard_smp_processor_id(cpu),
|
|
|
|
VPHN_FLAG_VCPU, associativity);
|
2010-12-01 20:31:15 +08:00
|
|
|
|
|
|
|
switch (rc) {
|
2020-01-29 21:52:58 +08:00
|
|
|
case H_SUCCESS:
|
2021-08-26 18:05:17 +08:00
|
|
|
pr_debug("VPHN hcall succeeded. Reset polling...\n");
|
2020-01-29 21:52:58 +08:00
|
|
|
goto out;
|
|
|
|
|
2010-12-01 20:31:15 +08:00
|
|
|
case H_FUNCTION:
|
2020-01-29 21:52:58 +08:00
|
|
|
pr_err_ratelimited("VPHN unsupported. Disabling polling...\n");
|
2010-12-01 20:31:15 +08:00
|
|
|
break;
|
|
|
|
case H_HARDWARE:
|
2020-01-29 21:52:58 +08:00
|
|
|
pr_err_ratelimited("hcall_vphn() experienced a hardware fault "
|
2010-12-01 20:31:15 +08:00
|
|
|
"preventing VPHN. Disabling polling...\n");
|
2017-09-09 04:47:27 +08:00
|
|
|
break;
|
2020-01-29 21:52:58 +08:00
|
|
|
case H_PARAMETER:
|
|
|
|
pr_err_ratelimited("hcall_vphn() was passed an invalid parameter. "
|
|
|
|
"Disabling polling...\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
pr_err_ratelimited("hcall_vphn() returned %ld. Disabling polling...\n"
|
|
|
|
, rc);
|
2017-09-09 04:47:27 +08:00
|
|
|
break;
|
2010-12-01 20:31:15 +08:00
|
|
|
}
|
2020-01-29 21:52:58 +08:00
|
|
|
out:
|
2010-12-01 20:31:15 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2017-11-29 06:58:43 +08:00
|
|
|
int find_and_online_cpu_nid(int cpu)
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
{
|
|
|
|
__be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
|
|
|
|
int new_nid;
|
|
|
|
|
|
|
|
/* Use associativity from first thread for all siblings */
|
2018-09-25 20:25:15 +08:00
|
|
|
if (vphn_get_associativity(cpu, associativity))
|
|
|
|
return cpu_to_node(cpu);
|
|
|
|
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
new_nid = associativity_to_nid(associativity);
|
|
|
|
if (new_nid < 0 || !node_possible(new_nid))
|
|
|
|
new_nid = first_online_node;
|
|
|
|
|
|
|
|
if (NODE_DATA(new_nid) == NULL) {
|
|
|
|
#ifdef CONFIG_MEMORY_HOTPLUG
|
|
|
|
/*
|
|
|
|
* Need to ensure that NODE_DATA is initialized for a node from
|
|
|
|
* available memory (see memblock_alloc_try_nid). If unable to
|
|
|
|
* init the node, then default to nearest node that has memory
|
powerpc/numa: Skip onlining a offline node in kdump path
With commit 2ea626306810 ("powerpc/topology: Get topology for shared
processors at boot"), kdump kernel on shared LPAR may crash.
The necessary conditions are
- Shared LPAR with at least 2 nodes having memory and CPUs.
- Memory requirement for kdump kernel must be met by the first N-1
nodes where there are at least N nodes with memory and CPUs.
Example numactl of such a machine.
$ numactl -H
available: 5 nodes (0,2,5-7)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 2 cpus:
node 2 size: 255 MB
node 2 free: 189 MB
node 5 cpus: 24 25 26 27 28 29 30 31
node 5 size: 4095 MB
node 5 free: 4024 MB
node 6 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 6 size: 6353 MB
node 6 free: 5998 MB
node 7 cpus: 8 9 10 11 12 13 14 15 32 33 34 35 36 37 38 39
node 7 size: 7640 MB
node 7 free: 7164 MB
node distances:
node 0 2 5 6 7
0: 10 40 40 40 40
2: 40 10 40 40 40
5: 40 40 10 40 40
6: 40 40 40 10 20
7: 40 40 40 20 10
Steps to reproduce.
1. Load / start kdump service.
2. Trigger a kdump (for example : echo c > /proc/sysrq-trigger)
When booting a kdump kernel with 2048M:
kexec: Starting switchover sequence.
I'm in purgatory
Using 1TB segments
hash-mmu: Initializing hash mmu with SLB
Linux version 4.19.0-rc5-master+ (srikar@linux-xxu6) (gcc version 4.8.5 (SUSE Linux)) #1 SMP Thu Sep 27 19:45:00 IST 2018
Found initrd at 0xc000000009e70000:0xc00000000ae554b4
Using pSeries machine description
-----------------------------------------------------
ppc64_pft_size = 0x1e
phys_mem_size = 0x88000000
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0x000000ff8f5d91a7
possible = 0x0000fbffcf5fb1a7
always = 0x0000006f8b5c91a1
cpu_user_features = 0xdc0065c2 0xef000000
mmu_features = 0x7c006001
firmware_features = 0x00000007c45bfc57
htab_hash_mask = 0x7fffff
physical_start = 0x8000000
-----------------------------------------------------
numa: NODE_DATA [mem 0x87d5e300-0x87d67fff]
numa: NODE_DATA(0) on node 6
numa: NODE_DATA [mem 0x87d54600-0x87d5e2ff]
Top of RAM: 0x88000000, Total RAM: 0x88000000
Memory hole size: 0MB
Zone ranges:
DMA [mem 0x0000000000000000-0x0000000087ffffff]
DMA32 empty
Normal empty
Movable zone start for each node
Early memory node ranges
node 6: [mem 0x0000000000000000-0x0000000087ffffff]
Could not find start_pfn for node 0
Initmem setup node 0 [mem 0x0000000000000000-0x0000000000000000]
On node 0 totalpages: 0
Initmem setup node 6 [mem 0x0000000000000000-0x0000000087ffffff]
On node 6 totalpages: 34816
Unable to handle kernel paging request for data at address 0x00000060
Faulting instruction address: 0xc000000008703a54
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 11 PID: 1 Comm: swapper/11 Not tainted 4.19.0-rc5-master+ #1
NIP: c000000008703a54 LR: c000000008703a38 CTR: 0000000000000000
REGS: c00000000b673440 TRAP: 0380 Not tainted (4.19.0-rc5-master+)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 24022022 XER: 20000002
CFAR: c0000000086fc238 IRQMASK: 0
GPR00: c000000008703a38 c00000000b6736c0 c000000009281900 0000000000000000
GPR04: 0000000000000000 0000000000000000 fffffffffffff001 c00000000b660080
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000220
GPR12: 0000000000002200 c000000009e51400 0000000000000000 0000000000000008
GPR16: 0000000000000000 c000000008c152e8 c000000008c152a8 0000000000000000
GPR20: c000000009422fd8 c000000009412fd8 c000000009426040 0000000000000008
GPR24: 0000000000000000 0000000000000000 c000000009168bc8 c000000009168c78
GPR28: c00000000b126410 0000000000000000 c00000000916a0b8 c00000000b126400
NIP [c000000008703a54] bus_add_device+0x84/0x1e0
LR [c000000008703a38] bus_add_device+0x68/0x1e0
Call Trace:
[c00000000b6736c0] [c000000008703a38] bus_add_device+0x68/0x1e0 (unreliable)
[c00000000b673740] [c000000008700194] device_add+0x454/0x7c0
[c00000000b673800] [c00000000872e660] __register_one_node+0xb0/0x240
[c00000000b673860] [c00000000839a6bc] __try_online_node+0x12c/0x180
[c00000000b673900] [c00000000839b978] try_online_node+0x58/0x90
[c00000000b673930] [c0000000080846d8] find_and_online_cpu_nid+0x158/0x190
[c00000000b673a10] [c0000000080848a0] numa_update_cpu_topology+0x190/0x580
[c00000000b673c00] [c000000008d3f2e4] smp_cpus_done+0x94/0x108
[c00000000b673c70] [c000000008d5c00c] smp_init+0x174/0x19c
[c00000000b673d00] [c000000008d346b8] kernel_init_freeable+0x1e0/0x450
[c00000000b673dc0] [c0000000080102e8] kernel_init+0x28/0x160
[c00000000b673e30] [c00000000800b65c] ret_from_kernel_thread+0x5c/0x80
Instruction dump:
60000000 60000000 e89e0020 7fe3fb78 4bff87d5 60000000 7c7d1b79 4082008c
e8bf0050 e93e0098 3b9f0010 2fa50000 <e8690060> 38630018 419e0114 7f84e378
---[ end trace 593577668c2daa65 ]---
However a regular kernel with 4096M (2048 gets reserved for crash
kernel) boots properly.
Unlike regular kernels, which mark all available nodes as online,
kdump kernel only marks just enough nodes as online and marks the rest
as offline at boot. However kdump kernel boots with all available
CPUs. With Commit 2ea626306810 ("powerpc/topology: Get topology for
shared processors at boot"), all CPUs are onlined on their respective
nodes at boot time. try_online_node() tries to online the offline
nodes but fails as all needed subsystems are not yet initialized.
As part of fix, detect and skip early onlining of a offline node.
Fixes: 2ea626306810 ("powerpc/topology: Get topology for shared processors at boot")
Reported-by: Pavithra Prakash <pavrampu@in.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Tested-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-28 11:47:32 +08:00
|
|
|
* installed. Skip onlining a node if the subsystems are not
|
|
|
|
* yet initialized.
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
*/
|
powerpc/numa: Skip onlining a offline node in kdump path
With commit 2ea626306810 ("powerpc/topology: Get topology for shared
processors at boot"), kdump kernel on shared LPAR may crash.
The necessary conditions are
- Shared LPAR with at least 2 nodes having memory and CPUs.
- Memory requirement for kdump kernel must be met by the first N-1
nodes where there are at least N nodes with memory and CPUs.
Example numactl of such a machine.
$ numactl -H
available: 5 nodes (0,2,5-7)
node 0 cpus:
node 0 size: 0 MB
node 0 free: 0 MB
node 2 cpus:
node 2 size: 255 MB
node 2 free: 189 MB
node 5 cpus: 24 25 26 27 28 29 30 31
node 5 size: 4095 MB
node 5 free: 4024 MB
node 6 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 6 size: 6353 MB
node 6 free: 5998 MB
node 7 cpus: 8 9 10 11 12 13 14 15 32 33 34 35 36 37 38 39
node 7 size: 7640 MB
node 7 free: 7164 MB
node distances:
node 0 2 5 6 7
0: 10 40 40 40 40
2: 40 10 40 40 40
5: 40 40 10 40 40
6: 40 40 40 10 20
7: 40 40 40 20 10
Steps to reproduce.
1. Load / start kdump service.
2. Trigger a kdump (for example : echo c > /proc/sysrq-trigger)
When booting a kdump kernel with 2048M:
kexec: Starting switchover sequence.
I'm in purgatory
Using 1TB segments
hash-mmu: Initializing hash mmu with SLB
Linux version 4.19.0-rc5-master+ (srikar@linux-xxu6) (gcc version 4.8.5 (SUSE Linux)) #1 SMP Thu Sep 27 19:45:00 IST 2018
Found initrd at 0xc000000009e70000:0xc00000000ae554b4
Using pSeries machine description
-----------------------------------------------------
ppc64_pft_size = 0x1e
phys_mem_size = 0x88000000
dcache_bsize = 0x80
icache_bsize = 0x80
cpu_features = 0x000000ff8f5d91a7
possible = 0x0000fbffcf5fb1a7
always = 0x0000006f8b5c91a1
cpu_user_features = 0xdc0065c2 0xef000000
mmu_features = 0x7c006001
firmware_features = 0x00000007c45bfc57
htab_hash_mask = 0x7fffff
physical_start = 0x8000000
-----------------------------------------------------
numa: NODE_DATA [mem 0x87d5e300-0x87d67fff]
numa: NODE_DATA(0) on node 6
numa: NODE_DATA [mem 0x87d54600-0x87d5e2ff]
Top of RAM: 0x88000000, Total RAM: 0x88000000
Memory hole size: 0MB
Zone ranges:
DMA [mem 0x0000000000000000-0x0000000087ffffff]
DMA32 empty
Normal empty
Movable zone start for each node
Early memory node ranges
node 6: [mem 0x0000000000000000-0x0000000087ffffff]
Could not find start_pfn for node 0
Initmem setup node 0 [mem 0x0000000000000000-0x0000000000000000]
On node 0 totalpages: 0
Initmem setup node 6 [mem 0x0000000000000000-0x0000000087ffffff]
On node 6 totalpages: 34816
Unable to handle kernel paging request for data at address 0x00000060
Faulting instruction address: 0xc000000008703a54
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 11 PID: 1 Comm: swapper/11 Not tainted 4.19.0-rc5-master+ #1
NIP: c000000008703a54 LR: c000000008703a38 CTR: 0000000000000000
REGS: c00000000b673440 TRAP: 0380 Not tainted (4.19.0-rc5-master+)
MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 24022022 XER: 20000002
CFAR: c0000000086fc238 IRQMASK: 0
GPR00: c000000008703a38 c00000000b6736c0 c000000009281900 0000000000000000
GPR04: 0000000000000000 0000000000000000 fffffffffffff001 c00000000b660080
GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000220
GPR12: 0000000000002200 c000000009e51400 0000000000000000 0000000000000008
GPR16: 0000000000000000 c000000008c152e8 c000000008c152a8 0000000000000000
GPR20: c000000009422fd8 c000000009412fd8 c000000009426040 0000000000000008
GPR24: 0000000000000000 0000000000000000 c000000009168bc8 c000000009168c78
GPR28: c00000000b126410 0000000000000000 c00000000916a0b8 c00000000b126400
NIP [c000000008703a54] bus_add_device+0x84/0x1e0
LR [c000000008703a38] bus_add_device+0x68/0x1e0
Call Trace:
[c00000000b6736c0] [c000000008703a38] bus_add_device+0x68/0x1e0 (unreliable)
[c00000000b673740] [c000000008700194] device_add+0x454/0x7c0
[c00000000b673800] [c00000000872e660] __register_one_node+0xb0/0x240
[c00000000b673860] [c00000000839a6bc] __try_online_node+0x12c/0x180
[c00000000b673900] [c00000000839b978] try_online_node+0x58/0x90
[c00000000b673930] [c0000000080846d8] find_and_online_cpu_nid+0x158/0x190
[c00000000b673a10] [c0000000080848a0] numa_update_cpu_topology+0x190/0x580
[c00000000b673c00] [c000000008d3f2e4] smp_cpus_done+0x94/0x108
[c00000000b673c70] [c000000008d5c00c] smp_init+0x174/0x19c
[c00000000b673d00] [c000000008d346b8] kernel_init_freeable+0x1e0/0x450
[c00000000b673dc0] [c0000000080102e8] kernel_init+0x28/0x160
[c00000000b673e30] [c00000000800b65c] ret_from_kernel_thread+0x5c/0x80
Instruction dump:
60000000 60000000 e89e0020 7fe3fb78 4bff87d5 60000000 7c7d1b79 4082008c
e8bf0050 e93e0098 3b9f0010 2fa50000 <e8690060> 38630018 419e0114 7f84e378
---[ end trace 593577668c2daa65 ]---
However a regular kernel with 4096M (2048 gets reserved for crash
kernel) boots properly.
Unlike regular kernels, which mark all available nodes as online,
kdump kernel only marks just enough nodes as online and marks the rest
as offline at boot. However kdump kernel boots with all available
CPUs. With Commit 2ea626306810 ("powerpc/topology: Get topology for
shared processors at boot"), all CPUs are onlined on their respective
nodes at boot time. try_online_node() tries to online the offline
nodes but fails as all needed subsystems are not yet initialized.
As part of fix, detect and skip early onlining of a offline node.
Fixes: 2ea626306810 ("powerpc/topology: Get topology for shared processors at boot")
Reported-by: Pavithra Prakash <pavrampu@in.ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Tested-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2018-09-28 11:47:32 +08:00
|
|
|
if (!topology_inited || try_online_node(new_nid))
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
new_nid = first_online_node;
|
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* Default to using the nearest node that has memory installed.
|
|
|
|
* Otherwise, it would be necessary to patch the kernel MM code
|
|
|
|
* to deal with more memoryless-node error conditions.
|
|
|
|
*/
|
|
|
|
new_nid = first_online_node;
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2017-11-29 06:58:43 +08:00
|
|
|
pr_debug("%s:%d cpu %d nid %d\n", __FUNCTION__, __LINE__,
|
|
|
|
cpu, new_nid);
|
powerpc/numa: Ensure nodes initialized for hotplug
This patch fixes some problems encountered at runtime with
configurations that support memory-less nodes, or that hot-add CPUs
into nodes that are memoryless during system execution after boot. The
problems of interest include:
* Nodes known to powerpc to be memoryless at boot, but to have CPUs in
them are allowed to be 'possible' and 'online'. Memory allocations
for those nodes are taken from another node that does have memory
until and if memory is hot-added to the node.
* Nodes which have no resources assigned at boot, but which may still
be referenced subsequently by affinity or associativity attributes,
are kept in the list of 'possible' nodes for powerpc. Hot-add of
memory or CPUs to the system can reference these nodes and bring
them online instead of redirecting the references to one of the set
of nodes known to have memory at boot.
Note that this software operates under the context of CPU hotplug. We
are not doing memory hotplug in this code, but rather updating the
kernel's CPU topology (i.e. arch_update_cpu_topology /
numa_update_cpu_topology). We are initializing a node that may be used
by CPUs or memory before it can be referenced as invalid by a CPU
hotplug operation. CPU hotplug operations are protected by a range of
APIs including cpu_maps_update_begin/cpu_maps_update_done,
cpus_read/write_lock / cpus_read/write_unlock, device locks, and more.
Memory hotplug operations, including try_online_node, are protected by
mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the
case of CPUs being hot-added to a previously memoryless node, the
try_online_node operation occurs wholly within the CPU locks with no
overlap. Using HMC hot-add/hot-remove operations, we have been able to
add and remove CPUs to any possible node without failures. HMC
operations involve a degree self-serialization, though.
Signed-off-by: Michael Bringmann <mwb@linux.vnet.ibm.com>
Reviewed-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-11-29 06:58:40 +08:00
|
|
|
return new_nid;
|
|
|
|
}
|
|
|
|
|
2020-08-10 15:18:33 +08:00
|
|
|
int cpu_to_coregroup_id(int cpu)
|
|
|
|
{
|
2020-08-10 15:18:34 +08:00
|
|
|
__be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
|
|
|
|
int index;
|
|
|
|
|
|
|
|
if (cpu < 0 || cpu > nr_cpu_ids)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
if (!coregroup_enabled)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (!firmware_has_feature(FW_FEATURE_VPHN))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (vphn_get_associativity(cpu, associativity))
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
index = of_read_number(associativity, 1);
|
2021-08-12 21:22:19 +08:00
|
|
|
if (index > primary_domain_index + 1)
|
2020-08-10 15:18:34 +08:00
|
|
|
return of_read_number(&associativity[index - 1], 1);
|
|
|
|
|
|
|
|
out:
|
2020-08-10 15:18:33 +08:00
|
|
|
return cpu_to_core_id(cpu);
|
|
|
|
}
|
|
|
|
|
2013-04-24 14:07:39 +08:00
|
|
|
static int topology_update_init(void)
|
|
|
|
{
|
2017-09-09 04:47:27 +08:00
|
|
|
topology_inited = 1;
|
2013-04-24 14:07:39 +08:00
|
|
|
return 0;
|
2010-12-01 20:31:15 +08:00
|
|
|
}
|
2013-04-24 14:07:39 +08:00
|
|
|
device_initcall(topology_update_init);
|
2010-12-18 06:07:47 +08:00
|
|
|
#endif /* CONFIG_PPC_SPLPAR */
|