Re: [PATCH V2] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation
You are correct. I found a problem with multiple cores last week, and I have a new patch in testing. I will resubmit it after more testing. Sorry for the inconvenience. Michael On 01/27/2018 03:52 AM, Michael Ellerman wrote: > Michael Bringmann writes: > >> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c >> index b15bae2..0a49231 100644 >> --- a/arch/powerpc/kernel/prom.c >> +++ b/arch/powerpc/kernel/prom.c >> @@ -303,6 +306,71 @@ static void __init >> check_cpu_feature_properties(unsigned long node) >> } >> } >> >> +static void __init early_init_setup_thread_group_mask(unsigned long node, >> +cpumask_t *thread_group_mask) >> +{ >> +const __be32 *thrgrp; >> +int len, rc = 0; >> +u32 cc_type = 0, no_split = 0, thr_per_split = 0; >> +int j, k; >> + >> +cpumask_clear(thread_group_mask); >> + >> +thrgrp = of_get_flat_dt_prop(node, "ibm,thread-groups", &len); >> +if (!thrgrp) >> +return; > > This breaks booting on all my systems. > > cheers > -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 m...@linux.vnet.ibm.com
Re: [PATCH V2] powerpc/kernel: Add 'ibm, thread-groups' property for CPU allocation
Michael Bringmann writes: > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c > index b15bae2..0a49231 100644 > --- a/arch/powerpc/kernel/prom.c > +++ b/arch/powerpc/kernel/prom.c > @@ -303,6 +306,71 @@ static void __init check_cpu_feature_properties(unsigned > long node) > } > } > > +static void __init early_init_setup_thread_group_mask(unsigned long node, > + cpumask_t *thread_group_mask) > +{ > + const __be32 *thrgrp; > + int len, rc = 0; > + u32 cc_type = 0, no_split = 0, thr_per_split = 0; > + int j, k; > + > + cpumask_clear(thread_group_mask); > + > + thrgrp = of_get_flat_dt_prop(node, "ibm,thread-groups", &len); > + if (!thrgrp) > + return; This breaks booting on all my systems. cheers
Re: [PATCH V2] powerpc/kernel: Add 'ibm, thread-groups' property for CPU allocation
On 01/12/2018 08:33 PM, Michael Ellerman wrote: > Nathan Fontenot writes: ... >> >> One thing I don't see addressed in the comments or in the code is >> migration support. I think we need to update the thread group mask >> post-migration to reflect the threads per core on the new system. > > Normally I'd agree with you, but I don't see any prospect of the kernel > surviving if the threads per core changes across a migration. We'll have > data structures allocated based on the old value and things will > definitely crash if the value increases. If it shrinks maybe we'd get > away with it, but either way is dicey. > > If there's an expectation that we'll be able to migrate between systems > with different settings then we have a much bigger problem. > > cheers > > >From what I recall of my tests a few months ago, the device-tree is read in and flattened before the kernel starts processing the migration state. I am trying to get access to a couple of P9 systems on which I may test migration to verify the ordering of events between initializing the kernel and post-migration processing. Regards, -- Michael W. Bringmann Linux Technology Center IBM Corporation Tie-Line 363-5196 External: (512) 286-5196 Cell: (512) 466-0650 m...@linux.vnet.ibm.com
Re: [PATCH V2] powerpc/kernel: Add 'ibm, thread-groups' property for CPU allocation
Nathan Fontenot writes: > On 01/08/2018 11:19 AM, Michael Bringmann wrote: >> Add code to parse the new property 'ibm,thread-groups" when it is >> present. The content of this property explicitly defines the number >> of threads per core as well as the PowerPC 'threads_core_mask'. >> The design provides a common device-tree for both P9 normal core and >> P9 fused core systems. The new property has been observed to be >> available on P9 pHyp systems, but it is not always present on >> OpenPower BMC systems. >> >> The property updates the kernel to know which CPUs/threads of each >> core are actually present, and then use the map when adding cores >> to the system at boot, or during hotplug operations. >> >> * Previously, the information about the number of threads per core >> was inferred solely from the "ibm,ppc-interrupt-server#s" property >> in the system device tree. >> * Also previous to this property, The mask of threads per CPU was >> inferred to be a strict linear series from 0..(nthreads-1). >> * After reading the "ibm,thread-group" property, we can determine >> the number of threads per core to be the 'bitmask weight' of the >> CPU thread mask. >> * Also after reading the property, we can determine which of the >> possible threads we are allowed to online for each CPU. It is no >> longer a simple linear sequence, but may be discontinuous e.g. >> activate threads 1,2,3,5,6,7 on a core instead of 0-5 sequentially. >> >> Implementation of the "ibm,thread-groups" property is spread across >> a few files in the powerpc specific code: >> >> * prom.c: Parse the property and create 'ppc_thread_group_mask'. >> Use the mask in operation of early_init_dt_scan_cpus(). >> * setup-common.c: Import 'ppc_thread_group_mask' and use the value >> in the operation of cpu_init_thread_core_maps(), and >> smp_setup_cpu_maps. >> * hotplug-cpu.c: Use 'ppc_thread_group_mask' in several locations >> where the code previously expected to iterate over a >> linear series of active threads (0..nthreads-1). >> >> Note that the "ibm,thread-groups" property also includes semantics >> of 'thread-group' i.e. define one or more subgroups of the available >> threads, each group of threads to be used for a specific class of >> task. Translating thread group semantics into Linux kernel features >> is TBD. > > One thing I don't see addressed in the comments or in the code is > migration support. I think we need to update the thread group mask > post-migration to reflect the threads per core on the new system. Normally I'd agree with you, but I don't see any prospect of the kernel surviving if the threads per core changes across a migration. We'll have data structures allocated based on the old value and things will definitely crash if the value increases. If it shrinks maybe we'd get away with it, but either way is dicey. If there's an expectation that we'll be able to migrate between systems with different settings then we have a much bigger problem. cheers
Re: [PATCH V2] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation
On 01/08/2018 11:19 AM, Michael Bringmann wrote: > Add code to parse the new property 'ibm,thread-groups" when it is > present. The content of this property explicitly defines the number > of threads per core as well as the PowerPC 'threads_core_mask'. > The design provides a common device-tree for both P9 normal core and > P9 fused core systems. The new property has been observed to be > available on P9 pHyp systems, but it is not always present on > OpenPower BMC systems. > > The property updates the kernel to know which CPUs/threads of each > core are actually present, and then use the map when adding cores > to the system at boot, or during hotplug operations. > > * Previously, the information about the number of threads per core > was inferred solely from the "ibm,ppc-interrupt-server#s" property > in the system device tree. > * Also previous to this property, The mask of threads per CPU was > inferred to be a strict linear series from 0..(nthreads-1). > * After reading the "ibm,thread-group" property, we can determine > the number of threads per core to be the 'bitmask weight' of the > CPU thread mask. > * Also after reading the property, we can determine which of the > possible threads we are allowed to online for each CPU. It is no > longer a simple linear sequence, but may be discontinuous e.g. > activate threads 1,2,3,5,6,7 on a core instead of 0-5 sequentially. > > Implementation of the "ibm,thread-groups" property is spread across > a few files in the powerpc specific code: > > * prom.c: Parse the property and create 'ppc_thread_group_mask'. > Use the mask in operation of early_init_dt_scan_cpus(). > * setup-common.c: Import 'ppc_thread_group_mask' and use the value > in the operation of cpu_init_thread_core_maps(), and > smp_setup_cpu_maps. > * hotplug-cpu.c: Use 'ppc_thread_group_mask' in several locations > where the code previously expected to iterate over a > linear series of active threads (0..nthreads-1). > > Note that the "ibm,thread-groups" property also includes semantics > of 'thread-group' i.e. define one or more subgroups of the available > threads, each group of threads to be used for a specific class of > task. Translating thread group semantics into Linux kernel features > is TBD. One thing I don't see addressed in the comments or in the code is migration support. I think we need to update the thread group mask post-migration to reflect the threads per core on the new system. -Nathan > > Signed-off-by: Michael Bringmann > --- > Changes in V2: > -- Add more information and examples to the patch description. > -- Rename 'pseries_thread_group_mask' to 'ppc_thread_group_mask' > -- Remove unnecessary debug message complaining about absence of > property. > -- Reduce indent complexity of early_init_dt_scan_cpus(). > --- > arch/powerpc/include/asm/cputhreads.h|2 + > arch/powerpc/kernel/prom.c | 74 > ++ > arch/powerpc/kernel/setup-common.c | 30 +++ > arch/powerpc/platforms/pseries/hotplug-cpu.c | 13 - > 4 files changed, 107 insertions(+), 12 deletions(-) > > diff --git a/arch/powerpc/include/asm/cputhreads.h > b/arch/powerpc/include/asm/cputhreads.h > index d71a909..8e444d4 100644 > --- a/arch/powerpc/include/asm/cputhreads.h > +++ b/arch/powerpc/include/asm/cputhreads.h > @@ -31,6 +31,8 @@ > #define threads_core_mask(*get_cpu_mask(0)) > #endif > > +extern cpumask_t ppc_thread_group_mask; > + > /* cpu_thread_mask_to_cores - Return a cpumask of one per cores > *hit by the argument > * > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c > index b15bae2..0a49231 100644 > --- a/arch/powerpc/kernel/prom.c > +++ b/arch/powerpc/kernel/prom.c > @@ -68,6 +68,9 @@ > #define DBG(fmt...) > #endif > > +cpumask_t ppc_thread_group_mask; > +EXPORT_SYMBOL(ppc_thread_group_mask); > + > #ifdef CONFIG_PPC64 > int __initdata iommu_is_off; > int __initdata iommu_force_on; > @@ -303,6 +306,71 @@ static void __init check_cpu_feature_properties(unsigned > long node) > } > } > > +static void __init early_init_setup_thread_group_mask(unsigned long node, > + cpumask_t *thread_group_mask) > +{ > + const __be32 *thrgrp; > + int len, rc = 0; > + u32 cc_type = 0, no_split = 0, thr_per_split = 0; > + int j, k; > + > + cpumask_clear(thread_group_mask); > + > + thrgrp = of_get_flat_dt_prop(node, "ibm,thread-groups", &len); > + if (!thrgrp) > + return; > + > + /* Process the thread groups for the Core thread mask */ > + /* Characteristic type per table */ > + cc_type = of_read_number(thrgrp++, 1); > + > + /* > + * 1 : Group shares common L1, translation cache, and > + * instruction data flow > + * >1 : Reserved > + */ > + if (cc_type != 1) { >
[PATCH V2] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation
Add code to parse the new property 'ibm,thread-groups" when it is present. The content of this property explicitly defines the number of threads per core as well as the PowerPC 'threads_core_mask'. The design provides a common device-tree for both P9 normal core and P9 fused core systems. The new property has been observed to be available on P9 pHyp systems, but it is not always present on OpenPower BMC systems. The property updates the kernel to know which CPUs/threads of each core are actually present, and then use the map when adding cores to the system at boot, or during hotplug operations. * Previously, the information about the number of threads per core was inferred solely from the "ibm,ppc-interrupt-server#s" property in the system device tree. * Also previous to this property, The mask of threads per CPU was inferred to be a strict linear series from 0..(nthreads-1). * After reading the "ibm,thread-group" property, we can determine the number of threads per core to be the 'bitmask weight' of the CPU thread mask. * Also after reading the property, we can determine which of the possible threads we are allowed to online for each CPU. It is no longer a simple linear sequence, but may be discontinuous e.g. activate threads 1,2,3,5,6,7 on a core instead of 0-5 sequentially. Implementation of the "ibm,thread-groups" property is spread across a few files in the powerpc specific code: * prom.c: Parse the property and create 'ppc_thread_group_mask'. Use the mask in operation of early_init_dt_scan_cpus(). * setup-common.c: Import 'ppc_thread_group_mask' and use the value in the operation of cpu_init_thread_core_maps(), and smp_setup_cpu_maps. * hotplug-cpu.c: Use 'ppc_thread_group_mask' in several locations where the code previously expected to iterate over a linear series of active threads (0..nthreads-1). Note that the "ibm,thread-groups" property also includes semantics of 'thread-group' i.e. define one or more subgroups of the available threads, each group of threads to be used for a specific class of task. Translating thread group semantics into Linux kernel features is TBD. Signed-off-by: Michael Bringmann --- Changes in V2: -- Add more information and examples to the patch description. -- Rename 'pseries_thread_group_mask' to 'ppc_thread_group_mask' -- Remove unnecessary debug message complaining about absence of property. -- Reduce indent complexity of early_init_dt_scan_cpus(). --- arch/powerpc/include/asm/cputhreads.h|2 + arch/powerpc/kernel/prom.c | 74 ++ arch/powerpc/kernel/setup-common.c | 30 +++ arch/powerpc/platforms/pseries/hotplug-cpu.c | 13 - 4 files changed, 107 insertions(+), 12 deletions(-) diff --git a/arch/powerpc/include/asm/cputhreads.h b/arch/powerpc/include/asm/cputhreads.h index d71a909..8e444d4 100644 --- a/arch/powerpc/include/asm/cputhreads.h +++ b/arch/powerpc/include/asm/cputhreads.h @@ -31,6 +31,8 @@ #define threads_core_mask (*get_cpu_mask(0)) #endif +extern cpumask_t ppc_thread_group_mask; + /* cpu_thread_mask_to_cores - Return a cpumask of one per cores *hit by the argument * diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index b15bae2..0a49231 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -68,6 +68,9 @@ #define DBG(fmt...) #endif +cpumask_t ppc_thread_group_mask; +EXPORT_SYMBOL(ppc_thread_group_mask); + #ifdef CONFIG_PPC64 int __initdata iommu_is_off; int __initdata iommu_force_on; @@ -303,6 +306,71 @@ static void __init check_cpu_feature_properties(unsigned long node) } } +static void __init early_init_setup_thread_group_mask(unsigned long node, + cpumask_t *thread_group_mask) +{ + const __be32 *thrgrp; + int len, rc = 0; + u32 cc_type = 0, no_split = 0, thr_per_split = 0; + int j, k; + + cpumask_clear(thread_group_mask); + + thrgrp = of_get_flat_dt_prop(node, "ibm,thread-groups", &len); + if (!thrgrp) + return; + + /* Process the thread groups for the Core thread mask */ + /* Characteristic type per table */ + cc_type = of_read_number(thrgrp++, 1); + + /* +* 1 : Group shares common L1, translation cache, and +* instruction data flow +* >1 : Reserved +*/ + if (cc_type != 1) { + rc = -EINVAL; + goto endit; + } + + /* No. splits */ + no_split = of_read_number(thrgrp++, 1); + if (no_split == 0) { + rc = -EINVAL; + goto endit; + } + + /* Threads per split */ + thr_per_split = of_read_number(thrgrp++, 1); + if (thr_per_split == 0) { + rc = -EINVAL; + goto endit; + } + + DBG("INFO: N