diff options
| author | Nathan Fontenot <nfont@linux.vnet.ibm.com> | 2018-10-29 13:43:36 -0500 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-04-05 22:34:46 +0200 |
| commit | b32cff3dd08623589da4c175e2de459131f6e6d9 (patch) | |
| tree | d54f6de5208bfad2b267c3bc9f7aec144875becd /tools/perf/util/scripting-engines/trace-event-python.c | |
| parent | 9ee0088f920b1862f998542228572729bb19dce8 (diff) | |
| download | talos-obmc-linux-b32cff3dd08623589da4c175e2de459131f6e6d9.tar.gz talos-obmc-linux-b32cff3dd08623589da4c175e2de459131f6e6d9.zip | |
powerpc/pseries: Perform full re-add of CPU for topology update post-migration
[ Upstream commit 81b61324922c67f73813d8a9c175f3c153f6a1c6 ]
On pseries systems, performing a partition migration can result in
altering the nodes a CPU is assigned to on the destination system. For
exampl, pre-migration on the source system CPUs are in node 1 and 3,
post-migration on the destination system CPUs are in nodes 2 and 3.
Handling the node change for a CPU can cause corruption in the slab
cache if we hit a timing where a CPUs node is changed while cache_reap()
is invoked. The corruption occurs because the slab cache code appears
to rely on the CPU and slab cache pages being on the same node.
The current dynamic updating of a CPUs node done in arch/powerpc/mm/numa.c
does not prevent us from hitting this scenario.
Changing the device tree property update notification handler that
recognizes an affinity change for a CPU to do a full DLPAR remove and
add of the CPU instead of dynamically changing its node resolves this
issue.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Tested-by: Michael W. Bringmann <mwb@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'tools/perf/util/scripting-engines/trace-event-python.c')
0 files changed, 0 insertions, 0 deletions
