mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-14 06:35:12 +00:00
9c7248bb8d
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:
|
||
|---|---|---|
| .. | ||
| book3s32 | ||
| book3s64 | ||
| kasan | ||
| nohash | ||
| ptdump | ||
| cacheflush.c | ||
| copro_fault.c | ||
| dma-noncoherent.c | ||
| drmem.c | ||
| fault.c | ||
| hugetlbpage.c | ||
| init-common.c | ||
| init_32.c | ||
| init_64.c | ||
| ioremap.c | ||
| ioremap_32.c | ||
| ioremap_64.c | ||
| maccess.c | ||
| Makefile | ||
| mem.c | ||
| mmap.c | ||
| mmu_context.c | ||
| mmu_decl.h | ||
| numa.c | ||
| pageattr.c | ||
| pgtable-frag.c | ||
| pgtable.c | ||
| pgtable_32.c | ||
| pgtable_64.c | ||
| slice.c | ||