Re: [tpmdd-devel] Has anyone a ATMEL TPM Chip on PPC64 (CONFIG_TCG_ATMEL)?
On 10/27/2013 05:06 PM, Peter Hüwe wrote: Hi, I was wondering if anyone here on this list still has a machine with an old ATMEL TPM (trusted platform module) lying around? From the kconfig entry it becomes evident that it was only supported on ppc64 machines. config TCG_ATMEL tristate Atmel TPM Interface depends on PPC64 || HAS_IOPORT ---help--- If you have a TPM security chip from Atmel say Yes and it will be accessible from within Linux. To compile this driver as a module, choose M here; the module will be called tpm_atmel. The hardware/driver is pretty old and the driver might have contained a bug that made it unusable for the last 6 years ;) So if anyone still has this kind of hardware around, please reply. As near as I can tell this was on a single machine type (the js21 circa 2006). The firmware on the machine didn't support establishing a root of trust, so use of the TPM was as a practical matter effective only for the other functions like random number generation and key management. The number of users who used the TPM for this on this machine was likely very small 7 years ago. The number of those machines still in service today is likely smaller still. The cross section of those two small numbers combined with those who want to run on a shiny new kernel has to be quickly approaching zero. I reccomend removing the driver. If the stars align and a user actually appears who wants to use one I'll clean up the driver and resubmit it for inclusion. I just don't think that will happen. -Joel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
Sorry for the slow reply, was on vacation. Mikey seems to have answered pretty well though. That is, unless these threads 2 and 3 really are _that_ weak, at which point one wonders why IBM bothered with the silicon ;-) Peter, 2 3 aren't weaker than 0 1 but The core has dynamic SMT mode switching which is controlled by the hypervisor (IBM's PHYP). There are 3 SMT modes: SMT1 uses thread 0 SMT2 uses threads 0 1 SMT4 uses threads 0, 1, 2 3 When in any particular SMT mode, all threads have the same performance as each other (ie. at any moment in time, all threads perform the same). The SMT mode switching works such that when linux has threads 2 3 idle and 0 1 active, it will cede (H_CEDE hypercall) threads 2 and 3 in the idle loop and the hypervisor will automatically switch to SMT2 for that core (independent of other cores). The opposite is not true, so if threads 0 1 are idle and 2 3 are active, we will stay in SMT4 mode. Similarly if thread 0 is active and threads 1, 2 3 are idle, we'll go into SMT1 mode. If we can get the core into a lower SMT mode (SMT1 is best), the threads will perform better (since they share less core resources). Hence when we have idle threads, we want them to be the higher ones. Just out of curiosity, is this a hardware constraint or a hypervisor constraint? hardware So to answer your question, threads 2 and 3 aren't weaker than the other threads when in SMT4 mode. It's that if we idle threads 2 3, threads 0 1 will speed up since we'll move to SMT2 mode. I'm pretty vague on linux scheduler details, so I'm a bit at sea as to how to solve this. Can you suggest any mechanisms we currently have in the kernel to reflect these properties, or do you think we need to develop something new? If so, any pointers as to where we should look? Since the threads speed up we'd need to change their weights at runtime regardless of placement. It just seems to make sense to let the changed weights affect placement naturally at the same time. Well there currently isn't one, and I've been telling people to create a new SD_flag to reflect this and influence the f_b_g() behaviour. Something like the below perhaps, totally untested and without comments so that you'll have to reverse engineer and validate my thinking. There's one fundamental assumption, and one weakness in the implementation. I'm going to guess the weakness is that it doesn't adjust the cpu power so tasks running in SMT1 mode actually get more than they account for? What's the assumption? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Version 3 adds the #ifdef to avoid compiling on kernels that don't need it
Index: linux-2.6.git/arch/powerpc/kernel/smp.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6.git/arch/powerpc/kernel/smp.c
@@ -620,3 +620,61 @@ void __cpu_die(unsigned int cpu)
smp_ops-cpu_die(cpu);
}
#endif
+
+#ifdef CONFIG_SCHED_SMT
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int sibling;
+ int idle_count = 0;
+ int thread;
+
+ /* Setup the default weight and smt_gain used by most cpus for SMT
+* Power. Doing this right away covers the default case and can be
+* used by cpus that modify it dynamically.
+*/
+ struct cpumask *sibling_map = sched_domain_span(sd);
+ unsigned long weight = cpumask_weight(sibling_map);
+ unsigned long smt_gain = sd-smt_gain;
+
+
+ if (cpu_has_feature(CPU_FTR_ASYNC_SMT4) weight == 4) {
+ for_each_cpu(sibling, sibling_map) {
+ if (idle_cpu(sibling))
+ idle_count++;
+ }
+
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count 1) {
+ thread = cpu_thread_in_core(cpu);
+ if (thread 2) {
+ /* add 75 % to thread power */
+ smt_gain += (smt_gain 1) + (smt_gain 2);
+ } else {
+/* subtract 75 % to thread power */
+ smt_gain = smt_gain 2;
+ }
+ }
+ }
+
+ /* default smt gain is 1178, weight is # of SMT threads */
+ switch (weight) {
+ case 1:
+ /*divide by 1, do nothing*/
+ break;
+ case 2:
+ smt_gain = smt_gain 1;
+ break;
+ case 4:
+ smt_gain = smt_gain 2;
+ break;
+ default:
+ smt_gain /= weight;
+ break;
+ }
+
+ return smt_gain;
+
+}
+#endif
Index: linux-2.6.git/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6.git.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.git/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAOLONG_ASM_CONST(0x0020)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080)
+#define CPU_FTR_ASYNC_SMT4 LONG_ASM_CONST(0x0100)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYNC_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2 2/2] Update ibm,client-architecture call field based on device tree
+ if(*cores != NR_CPUS) + prom_printf(client-architecture structure corrupted\n); + *cores = (NR_CPUS / prom_smt_way()); + prom_printf(setting client-architecture cores to %x\n, *cores); I don't know if I'm painting a bike shed of if this is a real concern, but if *cores isn't NR_CPUS shouldn't we do nothing rather then clobbering it? Yours Tony If it isn't NR_CPUS we're pretty broken if we set it or if we don't. My previous version did a BUILD_BUG_ON() but Ben didn't like that and said he preferred just a warning message. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 0/2] Add max CPU nodes field to ibm,client-architecture call
Large NUMA machines require Linux to indicate support for more than 64 cpu cores. This is done through the ibm,client-architecture call, and is documented in the PAPR. There is also another new field added to indicate that the OS is Linux as a hint for possible future performance settings. The first patch attempts to statically initialize the number of supported cores with NR_CPUS, the maximum Linux could boot if the cpus did not have multi-threading (SMT). It can overestimate by the factor of SMT. For instance on Power6 with 2 way SMT it would overestimate by a factor of 2. The result of this overestimation is that Linux might not be able boot all the cpus assigned to it, but would still boot NR_CPUS worth of SMT threads. The second patch adjusts for SMT by reading the device tree before unflattening. I've updated patch 1 from previous comments. Patch 1 can be taken on its own if Patch 2 seems like overkill. v2 - Updated patch 2 style and messages. Basic functionality is the same as v1. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
Gabriel Paubert wrote: On Thu, Jan 28, 2010 at 05:20:55PM -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. Really 2, 3, or 4? When you have 4 idle threads out of 4, performance becomes a minor concern, no? ;-) Gabriel Yes, but going from 4 idle to 3 idle you want to keep the slanted weights. If you ignored 4 you'd place wrong and then correct it after the fact. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
That said, I'm still not entirely convinced I like this usage of cpupower, its supposed to be a normalization scale for load-balancing, not a placement hook. Even if you do a placement hook you'll need to address it in the load balancing as well. Consider a single 4 thread SMT core with 4 running tasks. If 2 of them exit the remaining 2 will need to be load balanced within the core in a way that takes into account the dynamic nature of the thread power. This patch does that. I'd be much happier with a SD_GROUP_ORDER or something like that, that works together with SD_PREFER_SIBLING to pack active tasks to cpus in ascending group order. I don't see this load-balancing patch as mutually exclusive with a patch to fix placement. But even if it is a mutually exclusive solution there is no reason we can't fix things now with this patch and then later take it out when it's fixed another way. This patch series is straightforward, non-intrusive, and without it the scheduler is broken on this processor. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
Benjamin Herrenschmidt wrote: On Thu, 2010-01-28 at 17:24 -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. This patch implements arch_scale_smt_power to dynamically update smt thread power in these idle cases in order to prefer threads 0,1 over threads 2,3 within a core. Almost there :-) Joel, Peter, can you help me figure something out tho ? On machine that don't have SMT, I would like to avoid calling arch_scale_smt_power() at all if possible (in addition to not compiling it in if SMT is not enabled in .config). Now, I must say I'm utterly confused by how the domains are setup and I haven't quite managed to sort it out... it looks to me that SD_SHARE_CPUPOWER is always going to be set on all CPUs when the config option is set (though each CPU will have its own domain) or am I misguided ? IE. Is there any sense in having at least a fast exit path out of arch_scale_smt_power() for non-SMT CPUs ? Joel, can you look at compiling it out when SMT is not set ? We don't want to bloat SMP kernels for 32-bit non-SMT embedded platforms. I can wrap the powerpc definition of arch_scale_smt in an #ifdef, if it's not there the scheduler uses the default, which is the same as it uses if SMT isn't compiled. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv3 0/2] sched: arch_scale_smt_powers
The new Power7 processor has 4 way SMT. This 4 way SMT benefits from dynamic power updates that arch_scale_smt_power was designed to provide. The first patch fixes a generic scheduler bug necessary for arch_scale_smt to properly function. The second patch implements arch_scale_smt_power for powerpc, and in particular for Power7 processors. Version 2 changes: - Drop Patch 1 from the original series since it's in the -tip tree now - Move enabling the cpu feature into it's own patch (now patch 1) - Add stubbing out broken x86 implementation to patch 1 - clean up coding style in patch 2 Version 3 changes: - Added a comment to Patch 2 --- Joel Schopp (2): powerpc: implement arch_scale_smt_power for Power7 sched: enable ARCH_POWER arch/powerpc/include/asm/cputable.h |3 + arch/powerpc/kernel/smp.c | 56 arch/x86/kernel/cpu/sched.c |6 +-- kernel/sched_features.h |2 - 4 files changed, 61 insertions(+), 6 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv3 1/2] sched: enable ARCH_POWER
Enable the scheduler feature that allows use of arch_scale_smt_power. Stub out
the broken x86 implementation.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Index: linux-2.6.git/kernel/sched_features.h
===
--- linux-2.6.git.orig/kernel/sched_features.h
+++ linux-2.6.git/kernel/sched_features.h
@@ -102,7 +102,7 @@ SCHED_FEAT(CACHE_HOT_BUDDY, 1)
/*
* Use arch dependent cpu power functions
*/
-SCHED_FEAT(ARCH_POWER, 0)
+SCHED_FEAT(ARCH_POWER, 1)
SCHED_FEAT(HRTICK, 0)
SCHED_FEAT(DOUBLE_TICK, 0)
Index: linux-2.6.git/arch/x86/kernel/cpu/sched.c
===
--- linux-2.6.git.orig/arch/x86/kernel/cpu/sched.c
+++ linux-2.6.git/arch/x86/kernel/cpu/sched.c
@@ -44,11 +44,9 @@ unsigned long arch_scale_freq_power(stru
unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
{
/*
-* aperf/mperf already includes the smt gain
+* aperf/mperf already includes the smt gain, but represents capacity
+* as 0 when idle. So for now just return default.
*/
- if (boot_cpu_has(X86_FEATURE_APERFMPERF))
- return SCHED_LOAD_SCALE;
-
return default_scale_smt_power(sd, cpu);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Version 2 addresses style and optimization, same basic functionality
Version 3 adds a comment
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Version 2 addresses style and optimization, same basic functionality
Index: linux-2.6.git/arch/powerpc/kernel/smp.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6.git/arch/powerpc/kernel/smp.c
@@ -620,3 +620,59 @@ void __cpu_die(unsigned int cpu)
smp_ops-cpu_die(cpu);
}
#endif
+
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int sibling;
+ int idle_count = 0;
+ int thread;
+
+ /* Setup the default weight and smt_gain used by most cpus for SMT
+* Power. Doing this right away covers the default case and can be
+* used by cpus that modify it dynamically.
+*/
+ struct cpumask *sibling_map = sched_domain_span(sd);
+ unsigned long weight = cpumask_weight(sibling_map);
+ unsigned long smt_gain = sd-smt_gain;
+
+
+ if (cpu_has_feature(CPU_FTR_ASYNC_SMT4) weight == 4) {
+ for_each_cpu(sibling, sibling_map) {
+ if (idle_cpu(sibling))
+ idle_count++;
+ }
+
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count 1) {
+ thread = cpu_thread_in_core(cpu);
+ if (thread 2) {
+ /* add 75 % to thread power */
+ smt_gain += (smt_gain 1) + (smt_gain 2);
+ } else {
+/* subtract 75 % to thread power */
+ smt_gain = smt_gain 2;
+ }
+ }
+ }
+
+ /* default smt gain is 1178, weight is # of SMT threads */
+ switch (weight) {
+ case 1:
+ /*divide by 1, do nothing*/
+ break;
+ case 2:
+ smt_gain = smt_gain 1;
+ break;
+ case 4:
+ smt_gain = smt_gain 2;
+ break;
+ default:
+ smt_gain /= weight;
+ break;
+ }
+
+ return smt_gain;
+
+}
Index: linux-2.6.git/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6.git.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.git/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAOLONG_ASM_CONST(0x0020)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080)
+#define CPU_FTR_ASYNC_SMT4 LONG_ASM_CONST(0x0100)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYNC_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv3 2/2] powerpc: implement arch_scale_smt_power for Power7
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Version 2 addresses style and optimization, same basic functionality
Version 3 adds a comment, resent due to mailing format error
Index: linux-2.6.git/arch/powerpc/kernel/smp.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6.git/arch/powerpc/kernel/smp.c
@@ -620,3 +620,59 @@ void __cpu_die(unsigned int cpu)
smp_ops-cpu_die(cpu);
}
#endif
+
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int sibling;
+ int idle_count = 0;
+ int thread;
+
+ /* Setup the default weight and smt_gain used by most cpus for SMT
+* Power. Doing this right away covers the default case and can be
+* used by cpus that modify it dynamically.
+*/
+ struct cpumask *sibling_map = sched_domain_span(sd);
+ unsigned long weight = cpumask_weight(sibling_map);
+ unsigned long smt_gain = sd-smt_gain;
+
+
+ if (cpu_has_feature(CPU_FTR_ASYNC_SMT4) weight == 4) {
+ for_each_cpu(sibling, sibling_map) {
+ if (idle_cpu(sibling))
+ idle_count++;
+ }
+
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count 1) {
+ thread = cpu_thread_in_core(cpu);
+ if (thread 2) {
+ /* add 75 % to thread power */
+ smt_gain += (smt_gain 1) + (smt_gain 2);
+ } else {
+/* subtract 75 % to thread power */
+ smt_gain = smt_gain 2;
+ }
+ }
+ }
+
+ /* default smt gain is 1178, weight is # of SMT threads */
+ switch (weight) {
+ case 1:
+ /*divide by 1, do nothing*/
+ break;
+ case 2:
+ smt_gain = smt_gain 1;
+ break;
+ case 4:
+ smt_gain = smt_gain 2;
+ break;
+ default:
+ smt_gain /= weight;
+ break;
+ }
+
+ return smt_gain;
+
+}
Index: linux-2.6.git/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6.git.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.git/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAOLONG_ASM_CONST(0x0020)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080)
+#define CPU_FTR_ASYNC_SMT4 LONG_ASM_CONST(0x0100)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYNC_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 0/2] sched: arch_scale_smt_powers v2
The new Power7 processor has 4 way SMT. This 4 way SMT benefits from dynamic power updates that arch_scale_smt_power was designed to provide. The first patch fixes a generic scheduler bug necessary for arch_scale_smt to properly function. The second patch implements arch_scale_smt_power for powerpc, and in particular for Power7 processors. Version 2 changes: - Drop Patch 1 from the original series since it's in the -tip tree now - Move enabling the cpu feature into it's own patch (now patch 1) - Add stubbing out broken x86 implementation to patch 1 - clean up coding style in patch 2 --- Joel Schopp (2): powerpc: implement arch_scale_smt_power for Power7 sched: enable ARCH_POWER arch/powerpc/include/asm/cputable.h |3 +- arch/powerpc/kernel/smp.c | 52 arch/x86/kernel/cpu/sched.c |6 +--- kernel/sched_features.h |2 - 4 files changed, 57 insertions(+), 6 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 1/2] sched: enable ARCH_POWER
Enable the scheduler feature that allows use of arch_scale_smt_power. Stub out
the broken x86 implementation.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Index: linux-2.6.git/kernel/sched_features.h
===
--- linux-2.6.git.orig/kernel/sched_features.h
+++ linux-2.6.git/kernel/sched_features.h
@@ -102,7 +102,7 @@ SCHED_FEAT(CACHE_HOT_BUDDY, 1)
/*
* Use arch dependent cpu power functions
*/
-SCHED_FEAT(ARCH_POWER, 0)
+SCHED_FEAT(ARCH_POWER, 1)
SCHED_FEAT(HRTICK, 0)
SCHED_FEAT(DOUBLE_TICK, 0)
Index: linux-2.6.git/arch/x86/kernel/cpu/sched.c
===
--- linux-2.6.git.orig/arch/x86/kernel/cpu/sched.c
+++ linux-2.6.git/arch/x86/kernel/cpu/sched.c
@@ -44,11 +44,9 @@ unsigned long arch_scale_freq_power(stru
unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
{
/*
-* aperf/mperf already includes the smt gain
+* aperf/mperf already includes the smt gain, but represents capacity
+* as 0 when idle. So for now just return default.
*/
- if (boot_cpu_has(X86_FEATURE_APERFMPERF))
- return SCHED_LOAD_SCALE;
-
return default_scale_smt_power(sd, cpu);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 2/2] powerpc: implement arch_scale_smt_power for Power7
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
v2 - Same functionality as v1, better coding style.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Version 2 addresses style and optimization, same basic functionality
Index: linux-2.6.git/arch/powerpc/kernel/smp.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6.git/arch/powerpc/kernel/smp.c
@@ -620,3 +620,55 @@ void __cpu_die(unsigned int cpu)
smp_ops-cpu_die(cpu);
}
#endif
+
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int sibling;
+ int idle_count = 0;
+ int thread;
+
+ struct cpumask *sibling_map = sched_domain_span(sd);
+
+ unsigned long weight = cpumask_weight(sibling_map);
+ unsigned long smt_gain = sd-smt_gain;
+
+ if (cpu_has_feature(CPU_FTR_ASYNC_SMT4) weight == 4) {
+ for_each_cpu(sibling, sibling_map) {
+ if (idle_cpu(sibling))
+ idle_count++;
+ }
+
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count 1) {
+ thread = cpu_thread_in_core(cpu);
+ if (thread 2) {
+ /* add 75 % to thread power */
+ smt_gain += (smt_gain 1) + (smt_gain 2);
+ } else {
+/* subtract 75 % to thread power */
+ smt_gain = smt_gain 2;
+ }
+ }
+ }
+
+ /* default smt gain is 1178, weight is # of SMT threads */
+ switch (weight) {
+ case 1:
+ /*divide by 1, do nothing*/
+ break;
+ case 2:
+ smt_gain = smt_gain 1;
+ break;
+ case 4:
+ smt_gain = smt_gain 2;
+ break;
+ default:
+ smt_gain /= weight;
+ break;
+ }
+
+ return smt_gain;
+
+}
Index: linux-2.6.git/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6.git.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6.git/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAOLONG_ASM_CONST(0x0020)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080)
+#define CPU_FTR_ASYNC_SMT4 LONG_ASM_CONST(0x0100)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYNC_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
Benjamin Herrenschmidt wrote: On Wed, 2010-01-20 at 16:09 -0600, Joel Schopp wrote: I can turn that into a conditional branch (case statement) with a shift for the common 1,2,4 cases which should cover all procs available today falling back to a divide for any theoretical future processors that do other numbers of threads. Look at the cputhreads.h implementation ... Today we only support power-of-two numbers of threads. I've run 3 threads using cpu hotplug to offline 1 of the 4. It's certainly a stupid idea, but there you go. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] sched: arch_scale_smt_powers
The new Power7 processor has 4 way SMT. This 4 way SMT benefits from dynamic power updates that arch_scale_smt_power was designed to provide. The first patch fixes a generic scheduler bug necessary for arch_scale_smt to properly function. The second patch implements arch_scale_smt_power for powerpc, and in particular for Power7 processors. --- Gautham R Shenoy (1): sched: Fix the place where group powers are updated. Joel Schopp (1): powerpc: implement arch_scale_smt_power for Power7 arch/powerpc/kernel/smp.c | 41 + kernel/sched.c|7 +++ kernel/sched_features.h |2 +- 3 files changed, 45 insertions(+), 5 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] sched: Fix the place where group powers are updated.
From: Gautham R Shenoy e...@in.ibm.com
We want to update the sched_group_powers when balance_cpu == this_cpu.
Currently the group powers are updated only if the balance_cpu is the first
CPU in the local group. But balance_cpu = this_cpu could also be the first
idle cpu in the group. Hence fix the place where the group powers are updated.
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
kernel/sched.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/kernel/sched.c b/kernel/sched.c
index 281da29..5d2a451 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -3721,11 +3721,8 @@ static inline void update_sg_lb_stats(struct
sched_domain *sd,
unsigned long sum_avg_load_per_task;
unsigned long avg_load_per_task;
- if (local_group) {
+ if (local_group)
balance_cpu = group_first_cpu(group);
- if (balance_cpu == this_cpu)
- update_group_power(sd, this_cpu);
- }
/* Tally up the load of all CPUs in the group */
sum_avg_load_per_task = avg_load_per_task = 0;
@@ -3773,6 +3770,8 @@ static inline void update_sg_lb_stats(struct sched_domain
*sd,
return;
}
+ update_group_power(sd, this_cpu);
+
/* Adjust by relative CPU power of the group */
sgs-avg_load = (sgs-group_load * SCHED_LOAD_SCALE) / group-cpu_power;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads
there is performance benefit to idling the higher numbered threads in
the core.
This patch implements arch_scale_smt_power to dynamically update smt
thread power in these idle cases in order to prefer threads 0,1 over
threads 2,3 within a core.
Signed-off-by: Joel Schopp jsch...@austin.ibm.com
---
Index: linux-2.6.git/arch/powerpc/kernel/smp.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6.git/arch/powerpc/kernel/smp.c
@@ -617,3 +617,44 @@ void __cpu_die(unsigned int cpu)
smp_ops-cpu_die(cpu);
}
#endif
+
+static inline int thread_in_smt4core(int x)
+{
+ return x % 4;
+}
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int cpu2;
+ int idle_count = 0;
+
+ struct cpumask *cpu_map = sched_domain_span(sd);
+
+ unsigned long weight = cpumask_weight(cpu_map);
+ unsigned long smt_gain = sd-smt_gain;
+
+ if (cpu_has_feature(CPU_FTRS_POWER7) weight == 4) {
+ for_each_cpu(cpu2, cpu_map) {
+ if (idle_cpu(cpu2))
+ idle_count++;
+ }
+
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count == 2 || idle_count == 3 || idle_count == 4) {
+ if (thread_in_smt4core(cpu) == 0 ||
+ thread_in_smt4core(cpu) == 1) {
+ /* add 75 % to thread power */
+ smt_gain += (smt_gain 1) + (smt_gain 2);
+ } else {
+/* subtract 75 % to thread power */
+ smt_gain = smt_gain 2;
+ }
+ }
+ }
+ /* default smt gain is 1178, weight is # of SMT threads */
+ smt_gain /= weight;
+
+ return smt_gain;
+
+}
Index: linux-2.6.git/kernel/sched_features.h
===
--- linux-2.6.git.orig/kernel/sched_features.h
+++ linux-2.6.git/kernel/sched_features.h
@@ -107,7 +107,7 @@ SCHED_FEAT(CACHE_HOT_BUDDY, 1)
/*
* Use arch dependent cpu power functions
*/
-SCHED_FEAT(ARCH_POWER, 0)
+SCHED_FEAT(ARCH_POWER, 1)
SCHED_FEAT(HRTICK, 0)
SCHED_FEAT(DOUBLE_TICK, 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
+ if (cpu_has_feature(CPU_FTRS_POWER7) weight == 4) {
I think we should avoid using cpu_has_feature like this. It's better to
create a new feature and add it to POWER7 in the cputable, then check
for that here.
The way that it is now, I think any CPU that has superset of the POWER7
features, will be true here. This is not what we want.
Any ideas for what to call this feature? ASYM_SMT4 ?
+ smt_gain /= weight;
This results in a PPC div, when most of the time it's going to be a
power of two divide. You've optimised the divides a few lines above
this, but not this one. Some consistency would be good.
I can turn that into a conditional branch (case statement) with a shift
for the common 1,2,4 cases which should cover all procs available today
falling back to a divide for any theoretical future processors that do
other numbers of threads.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
+
+static inline int thread_in_smt4core(int x)
+{
+ return x % 4;
+}
Needs a whitespace here though I don't really like the above. Any reason
why you can't use the existing cpu_thread_in_core() ?
I will change it to cpu_thread_in_core()
+unsigned long arch_scale_smt_power(struct sched_domain *sd, int cpu)
+{
+ int cpu2;
+ int idle_count = 0;
+
+ struct cpumask *cpu_map = sched_domain_span(sd);
+
+ unsigned long weight = cpumask_weight(cpu_map);
+ unsigned long smt_gain = sd-smt_gain;
More whitespace damage above.
You are better than checkpatch.pl, will fix.
+ if (cpu_has_feature(CPU_FTRS_POWER7) weight == 4) {
+ for_each_cpu(cpu2, cpu_map) {
+ if (idle_cpu(cpu2))
+ idle_count++;
+ }
I'm not 100% sure about the use of the CPU feature above. First I wonder
if the right approach is to instead do something like
if (!cpu_has_feature(...) !! weigth 4)
return default_scale_smt_power(sd, cpu);
Though we may be better off using a ppc_md. hook here to avoid
calculating the weight etc... on processors that don't need any
of that.
I also dislike your naming. I would suggest you change cpu_map to
sibling_map() and cpu2 to sibling (or just c). One thing I wonder is how
sure we are that sched_domain_span() is always going to give us the
threads btw ? If we introduce another sched domain level for NUMA
purposes can't we get confused ?
Right now it's 100% always giving us threads. My development version of
the patch had a BUG_ON() to check this. I expect this to stay the case
in the future as the name of the function is arch_scale_smt_power(),
which clearly denotes threads are expected.
I am not stuck on the names, I'll change it to sibling instead of cpu2
and sibling_map instead of cpu_map. It seems clear to me either way.
As for testing the ! case it seems funcationally equivalent, and mine
seems less confusing.
Having a ppc.md hook with exactly 1 user is pointless, especially since
you'll still have to calculate the weight with the ability to
dynamically disable smt.
Also, how hot is this code path ?
It's every load balance, which is to say not hot, but fairly frequent.
I haven't been able to measure an impact from doing very hairy
calculations (without actually changing the weights) here vs not having
it at all in actual end workloads.
+ /* the following section attempts to tweak cpu power based
+* on current idleness of the threads dynamically at runtime
+*/
+ if (idle_count == 2 || idle_count == 3 || idle_count == 4) {
if (idle_count 1) ? :-)
Yes :) Originally I had done different weightings for each of the 3
cases, which gained in some workloads but regressed some others. But
since I'm not doing that anymore I'll fold it down to 1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: implement arch_scale_smt_power for Power7
Peter Zijlstra wrote: On Wed, 2010-01-20 at 14:04 -0600, Joel Schopp wrote: On Power7 processors running in SMT4 mode with 2, 3, or 4 idle threads there is performance benefit to idling the higher numbered threads in the core. So this is an actual performance improvement, not only power savings? Yes. And you just wrecked x86 ;-) It has an smt_power implementation that tries to measure smt gains using aperf/mperf, trouble is that this represents the actual performance not the capacity. This has the problem that when idle it represents 0 capacity and will not attract work. Coming up with something that actually works there is on the todo list, I was thinking perhaps temporal maximums from !idle. So if you want to go with this, you'll need to stub out arch/x86/kernel/cpu/sched.c OK. Guess I now will have a 3 patch series, with a patch to stub out the x86 broken version. Care to take Gautham's bugfix patch (patch 1/2) now, since it just fixes a bug? You'll need it if you ever try to make the x86 broken version work. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Add max CPU nodes field to ibm,client-architecture call
Large NUMA machines require Linux to indicate support for more than 64 cpu cores. This is done through the ibm,client-architecture call, and is documented in the PAPR. There is also another new field added to indicate that the OS is Linux as a hint for possible future performance settings. The first patch attempts to statically initialize the number of supported cores with NR_CPUS, the maximum Linux could boot if the cpus did not have multi-threading (SMT). It can overestimate by the factor of SMT. For instance on Power6 with 2 way SMT it would overestimate by a factor of 2. The result of this overestimation is that Linux might not be able boot all the cpus assigned to it, but would still boot NR_CPUS worth of SMT threads. The second patch adjusts for SMT by reading the device tree before unflattening. I've updated patch 1 from previous comments. Patch 1 can be taken on its own if Patch 2 seems like overkill. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] Update ibm,client-architecture call field based on device tree
In the previous patch the client-architecture field for the number of
cores supported is set statically as high as is possible. However, that
static setting could be too high if the system supports smt, resulting
in cpus assigned to Linux that are not booted. This patch reads the
device tree (before it is unflattened) to determine the amount of smt.
It then dynamically updates the entires in the array with the proper
number of cores supported. Tests show this correctly detecting SMT4 on
a Power7 and still booting all the supported cores on a large machine.
Signed-off-by:Joel Schoppjsch...@austin.ibm.com
Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c
===
--- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6.git/arch/powerpc/kernel/prom_init.c
@@ -141,6 +141,8 @@ typedef u32 cell_t;
extern void __start(unsigned long r3, unsigned long r4, unsigned long r5);
+static int __init prom_smt_way(void);
+
#ifdef CONFIG_PPC64
extern int enter_prom(struct prom_args *args, unsigned long entry);
#else
@@ -811,9 +813,17 @@ static void __init prom_send_capabilitie
{
ihandle elfloader, root;
prom_arg_t ret;
+ u32 *cores;
root = call_prom(open, 1, 1, ADDR(/));
if (root != 0) {
+ /*
+* If you add to the struct, please be sure the 100 index
+* didn't change. The BUILD_BUG_ON is a reminder.
+*/
+ BUILD_BUG_ON(sizeof(ibm_architecture_vec) != 108);
+ cores = (u32 *) ibm_architecture_vec[100];
+ *cores = (u32) (NR_CPUS/prom_smt_way());
/* try calling the ibm,client-architecture-support method */
prom_printf(Calling ibm,client-architecture-support...);
if (call_prom_ret(call-method, 3, 2, ret,
@@ -1031,6 +1041,45 @@ static void __init reserve_mem(u64 base,
RELOC(mem_reserve_cnt) = cnt + 1;
}
+
+static int __init prom_smt_way(void)
+{
+ phandle node;
+ char type[64];
+ unsigned int plen;
+
+ for (node = 0; prom_next_node(node); ) {
+ type[0] = 0;
+ prom_getprop(node, device_type, type, sizeof(type));
+
+ if (type[0] == 0) {
+ /*
+* CHRP Longtrail machines have no device_type
+* on the memory node, so check the name instead...
+*/
+ prom_getprop(node, name, type, sizeof(type));
+ }
+ if (strcmp(type, RELOC(cpu)))
+ continue;
+
+ /*
+* There is an entry for each smt thread, each entry being
+* 4 bytes long. All cpus should have the same number of
+* smt threads, so return after finding the first.
+*/
+ plen = prom_getproplen(node, ibm,ppc-interrupt-server#s);
+ prom_debug(smt %x\n, (unsigned long) plen);
+ if (plen = 4)
+ return plen / 4;
+ }
+ /*
+* If things go wrong and we get here fallback to SMT1
+*/
+ prom_debug(unable to determine smt from device tree, guessing smt1\n);
+ return 1;
+
+}
+
/*
* Initialize memory allocation mechanism, parse memory nodes and
* obtain that way the top of memory and RMO to setup out local allocator
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Add static fields to ibm,client-architecture call
This patch adds 2 fields to the ibm_architecture_vec array. The first of these fields indicates the number of cores which Linux can boot. It does not account for SMT, so it may result in cpus assigned to Linux which cannot be booted. A second patch follows that dynamically updates this for SMT. The second field just indicates that our OS is Linux, and not another OS. The system may or may not use this hint to performance tune settings for Linux. Sorry if the last version sent out got whitespace munged. Hopefully evolution works on this one. Signed-off-by:Joel Schoppjsch...@austin.ibm.com Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c === --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c @@ -654,6 +656,9 @@ static void __init early_cmdline_parse(v #define OV5_CMO0x00 #endif +/* Option Vector 6: IBM PAPR hints */ +#define OV6_LINUX 0x02/* Linux is our OS */ + /* * The architecture vector has an array of PVR mask/value pairs, * followed by # option vectors - 1, followed by the option vectors. @@ -665,7 +670,7 @@ static unsigned char ibm_architecture_ve W(0x), W(0x0f03), /* all 2.06-compliant */ W(0x), W(0x0f02), /* all 2.05-compliant */ W(0xfffe), W(0x0f01), /* all 2.04-compliant and earlier */ - 5 - 1, /* 5 option vectors */ + 6 - 1, /* 6 option vectors */ /* option vector 1: processor architectures supported */ 3 - 2, /* length */ @@ -697,12 +702,24 @@ static unsigned char ibm_architecture_ve 0, /* don't halt */ /* option vector 5: PAPR/OF options */ - 5 - 2, /* length */ + 13 - 2, /* length */ 0, /* don't ignore, don't halt */ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY | OV5_DONATE_DEDICATE_CPU | OV5_MSI, 0, OV5_CMO, + 0, + 0, + 0, + 0, + W(NR_CPUS), /* number of cores supported*/ + + /* option vector 6: IBM PAPR hints */ + 4 - 2, /* length */ + 0, + 0, + OV6_LINUX, + }; /* Old method - ELF header with PT_NOTE sections */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: update ibm,client-architecture
Subject: Re: [PATCH] powerpc: update ibm,client-architecture Please give this a more appropriate name. Any suggestions? In order to boot with more than 64 cores on machines that support the ibm,client-architecture RTAS call a new field has been added to the structure. This patch updates that field and adds a few others in the process. Please detail what these are here. OK. + W(NR_CPUS/4), /* max cores supported */ 4? 4 is the new 2. Since you don't know the actual threads per core at this point in boot you have to be conservative and go with the maximum number of any processor. See page 4 of these charts: http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf Can we do this now or remove the comment. Maybe UTS_RELEASE or something like that. I'll just remove the comment for now. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: update ibm,client-architecture
Tony Breeds wrote: On Fri, Dec 18, 2009 at 03:07:32PM -0600, Joel Schopp wrote: In order to boot with more than 64 cores on machines that support the ibm,client-architecture RTAS call a new field has been added to the structure. This patch updates that field and adds a few others in the process. It would be good if this could go in as a bugfix. But it's not really is it? What does it fix? It fixes kernels compiled with NR_CPUS where NR_CPUS 256. /* option vector 5: PAPR/OF options */ - 5 - 2, /* length */ + 13 - 2, /* length */ 0, /* don't ignore, don't halt */ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY | OV5_DONATE_DEDICATE_CPU | OV5_MSI, 0, OV5_CMO, + 0, /* reserved */ + 0, /* reserved */ + 0, /* reserved */ + 0, /* reserved */ Not so much reserved, as unused by us. They were all reserved until recently, and the last 2 of the 4 are still reserved, while we just don't use the first two yet. I'll remove the comments from the first 2. + W(NR_CPUS/4), /* max cores supported */ 4? I can see a case for 2 or just plain NR_CPUS, but 4 is wrong. 4 is the new 2. Since the actual threads per core is unknown at this point in boot you have to be conservative and go with the maximum number of any processor. See page 4 of these charts: http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf + /* option vector 6: IBM PAPR hints */ + 4 - 2, We all know this is a length, but please follow the style in this structure. OK. + 0, /* reserved */ + 0, /* 1 == no secondary pteg */ I think the 1 == confuses things. I'll remove it then. + OV6_LINUX, Does filling in the vector actually let us boot on systems where we do not already? Will add description to the email body on this one. + + /* option vector 7: IBM PAPR OS identification */ + /* a human readable ascii string will go here */ Either fill it in or leave the comments out. I'll leave the comment out. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: update ibm,client-architecture
OK. + W(NR_CPUS/4), /* max cores supported */ FYI reading the PAPR, this comment should technically be max 'cpu' nodes presented. I applied a disambiguation filter to the comment since cpus can mean a lot of things these days ( ie hardware threads, cores, chips) , but a core is a core. 4 is the new 2. I'd still be asking what 2 is. It's needs a #define to make clearer what you are doing. I'll add a #define Since you don't know the actual threads per core at this point in boot you have to be conservative and go with the maximum number of any processor. See page 4 of these charts: http://www.power.org/events/powercon09/taiwan09/IBM_Overview_POWER7.pdf I don't think hard wiring 4 in here is right. If we are booting a machine with SMT2, we will put only half the number of cores that we can handle in this field. This is going to break a lot of machines where people have compiled with NR_CPUS = thread number. I think you just want to put NR_CPUS here. It's a bad interface. No matter what you choose there will be a downside. 1) If you choose NR_CPUS, the best case of how many you could boot without SMT, then when you boot with SMT2 or SMT4 you can get assigned more cpus than you can boot. 2) If you choose NR_CPUS/4, the worst case of how many you could boot, and you get a large machine with SMT2 or SMT1 you might have said you support less cpus than you actually do and thus not boot all the cpus. So no matter what you choose you could be not booting cpus in some theoretical scenario. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: update ibm,client-architecture
In order to boot with more than 64 cores on machines that support the ibm,client-architecture RTAS call a new field has been added to the structure. This patch updates that field and adds a few others in the process. It would be good if this could go in as a bugfix. Signed-off-by: Joel Schopp jsch...@austin.ibm.com Index: linux-2.6.git/arch/powerpc/kernel/prom_init.c === --- linux-2.6.git.orig/arch/powerpc/kernel/prom_init.c +++ linux-2.6.git/arch/powerpc/kernel/prom_init.c @@ -654,6 +654,9 @@ static void __init early_cmdline_parse(v #define OV5_CMO0x00 #endif +/* Option Vector 6: IBM PAPR hints */ +#define OV6_LINUX 0x02/* Linux is our OS */ + /* * The architecture vector has an array of PVR mask/value pairs, * followed by # option vectors - 1, followed by the option vectors. @@ -665,7 +668,7 @@ static unsigned char ibm_architecture_ve W(0x), W(0x0f03), /* all 2.06-compliant */ W(0x), W(0x0f02), /* all 2.05-compliant */ W(0xfffe), W(0x0f01), /* all 2.04-compliant and earlier */ - 5 - 1, /* 5 option vectors */ + 6 - 1, /* 6 option vectors */ /* option vector 1: processor architectures supported */ 3 - 2, /* length */ @@ -697,12 +700,26 @@ static unsigned char ibm_architecture_ve 0, /* don't halt */ /* option vector 5: PAPR/OF options */ - 5 - 2, /* length */ + 13 - 2, /* length */ 0, /* don't ignore, don't halt */ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_DRCONF_MEMORY | OV5_DONATE_DEDICATE_CPU | OV5_MSI, 0, OV5_CMO, + 0, /* reserved */ + 0, /* reserved */ + 0, /* reserved */ + 0, /* reserved */ + W(NR_CPUS/4), /* max cores supported */ + + /* option vector 6: IBM PAPR hints */ + 4 - 2, + 0, /* reserved */ + 0, /* 1 == no secondary pteg */ + OV6_LINUX, + + /* option vector 7: IBM PAPR OS identification */ + /* a human readable ascii string will go here */ }; /* Old method - ELF header with PT_NOTE sections */ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] pseries: cpu: Reduce the polling interval in __cpu_up()
The code needs testing on other powerpc platforms.
I think given the numbers you showed this is a good improvement, and it
clearly can't do any harm on platforms that implement msleep correctly.
For what it's worth:
Acked-by: Joel Schopp jsch...@austin.ibm.com
Signed-off-by: Gautham R Shenoy e...@in.ibm.com
---
arch/powerpc/kernel/smp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 65484b2..00c13a1 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -411,9 +411,8 @@ int __cpuinit __cpu_up(unsigned int cpu)
* CPUs can take much longer to come up in the
* hotplug case. Wait five seconds.
*/
- for (c = 25; c !cpu_callin_map[cpu]; c--) {
- msleep(200);
- }
+ for (c = 5000; c !cpu_callin_map[cpu]; c--)
+ msleep(1);
#endif
if (!cpu_callin_map[cpu]) {
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH/RFC] 64 bit csum_partial_copy_generic
Thanks for doing this. A few comments below, but first, can you clarify what your and George Fulk's roles were in producing this? I had the impression George had written the code, and if that's the case, you need to put a From: George Fulk ... line as the first line of your mail when you re-send the patch. I wrote the patch, George wrote some very useful testcases. So a Tested-by: George Fulk [EMAIL PROTECTED] line would be appropriate, not sure if that line ever really caught on. As for the technical comments, I agree with all of them and will incorporate them into the next version. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Bugme-new] [Bug 11629] New: quad G5 fails to shut down
From: Johannes Berg [EMAIL PROTECTED] Subject: powerpc: fix shutdown I tracked down the shutdown regression to CPUs not dying when being shut down during power-off. This turns out to be due to the system_state being SYSTEM_POWER_OFF, which this code doesn't take as a valid state for shutting off CPUs in. This has never made sense to me, but when I added hotplug code to implement hibernate I only made it work and did not question the need to check the system_state. Thomas Gleixner helped me dig, but the only thing we found is that it was added with the original commit that added CPU hotplug support. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Cc: Thomas Gleixner [EMAIL PROTECTED] Cc: Joel Schopp [EMAIL PROTECTED] Cc: Benjamin Herrenschmidt [EMAIL PROTECTED] Tested this patch on a Power6 partition with cpu hotplug online/offline and some shutdown and reboot cycles. Didn't see any ill effects. Acked-by: Joel Schopp [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] 64 bit csum_partial_copy_generic
Did you consider the other alternative? If you work on 32-bit chunks instead of 64-bit chunks (either load them with lwz, or split them after loading with ld), you can add them up with a regular non-carrying add, which isn't serialising like adde; this also allows unrolling the loop (using several accumulators instead of just one). Since your registers are 64-bit, you can sum 16GB of data before ever getting a carry out. Or maybe the bottleneck here is purely the memory bandwidth? I think the main bottleneck is the bandwidth/latency of memory. When I sent the patch out I hadn't thought about eliminating the e from the add with 32 bit chunks. So I went off and tried it today and converting the existing function to use just add instead of adde (since it was only doing 32 bits already) and got 1.5% - 15.7% faster on Power5, which is nice, but was still way behind the new function in every testcase. I then added 1 level of unrolling to that (using 2 accumulators) and got 59% slower to 10% faster on Power5 depending on input. It seems quite a bit slower than I would have expected (I would have expected basically even), but thats what got measured. The comment in the existing function indicates unrolling the loop doesn't help because the bdnz has zero overhead, so I guess the unrolling hurt more than I expected. In any case I have now thought about it and don't think it will work out. Signed-off-by: Joel Schopp[EMAIL PROTECTED] You missed a space there. If at first you don't succeed... Signed-off-by: Joel Schopp [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 0/6] Strong Access Ordering page attributes for POWER7
We haven't defined a user-visible feature bit (and besides, we're really getting short on these...). This is becoming a bit of concern btw (the running out of bits). Maybe we should start defining an AT_HWCAP2 for powerpc and get libc updated to pick it up ? Joel, Any thoughts? Is it a required or optional feature of the 2.06 architecture spec? If it's required you could just use that. It doesn't solve the problem more generically if other archs decide to implement it though. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: Add cputable entry for POWER7
I'll send out some additional entries in a minute when I rebase what I
have on this. I think a couple of those lines were originally authored
by me so...
Signed-off-by: Joel Schopp [EMAIL PROTECTED]
Michael Neuling wrote:
Add a cputable entry for the POWER7 processor.
Also tell firmware that we know about POWER7.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
Paulus: please consider for your 2.6.27 tree.
arch/powerpc/kernel/cputable.c | 25 +
arch/powerpc/kernel/misc.S |5 +
arch/powerpc/kernel/prom_init.c |1 +
include/asm-powerpc/cputable.h | 12 ++--
4 files changed, 41 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/cputable.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/cputable.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/cputable.c
@@ -52,6 +52,8 @@ extern void __setup_cpu_ppc970MP(unsigne
extern void __setup_cpu_pa6t(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_pa6t(void);
extern void __restore_cpu_ppc970(void);
+extern void __setup_cpu_power7(unsigned long offset, struct cpu_spec* spec);
+extern void __restore_cpu_power7(void);
#endif /* CONFIG_PPC64 */
/* This table only contains desktop CPUs, it need to be filled with embedded
@@ -68,6 +70,9 @@ extern void __restore_cpu_ppc970(void);
#define COMMON_USER_POWER6 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
PPC_FEATURE_TRUE_LE)
+#define COMMON_USER_POWER7 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_06 |\
+PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
+PPC_FEATURE_TRUE_LE)
#define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
PPC_FEATURE_TRUE_LE | \
PPC_FEATURE_HAS_ALTIVEC_COMP)
@@ -380,6 +385,26 @@ static struct cpu_spec __initdata cpu_sp
.machine_check = machine_check_generic,
.platform = power6,
},
+ { /* Power7 */
+ .pvr_mask = 0x,
+ .pvr_value = 0x003f,
+ .cpu_name = POWER7,
+ .cpu_features = CPU_FTRS_POWER7,
+ .cpu_user_features = COMMON_USER_POWER7,
+ .icache_bsize = 128,
+ .dcache_bsize = 128,
+ .num_pmcs = 6,
+ .pmc_type = PPC_PMC_IBM,
+ .cpu_setup = __setup_cpu_power7,
+ .cpu_restore= __restore_cpu_power7,
+ .oprofile_cpu_type = ppc64/power7,
+ .oprofile_type = PPC_OPROFILE_POWER4,
+ .oprofile_mmcra_sihv= POWER6_MMCRA_SIHV,
+ .oprofile_mmcra_sipr= POWER6_MMCRA_SIPR,
+ .oprofile_mmcra_clear = POWER6_MMCRA_THRM |
+ POWER6_MMCRA_OTHER,
+ .platform = power7,
+ },
{ /* Cell Broadband Engine */
.pvr_mask = 0x,
.pvr_value = 0x0070,
Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc.S
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/misc.S
@@ -116,3 +116,8 @@ _GLOBAL(longjmp)
mtlrr0
mr r3,r4
blr
+
+_GLOBAL(__setup_cpu_power7)
+_GLOBAL(__restore_cpu_power7)
+ /* place holder */
+ blr
Index: linux-2.6-ozlabs/arch/powerpc/kernel/prom_init.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/prom_init.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/prom_init.c
@@ -650,6 +650,7 @@ static void __init early_cmdline_parse(v
static unsigned char ibm_architecture_vec[] = {
W(0xfffe), W(0x003a), /* POWER5/POWER5+ */
W(0x), W(0x003e), /* POWER6 */
+ W(0x), W(0x003f), /* POWER7 */
W(0x), W(0x0f02), /* all 2.05-compliant */
W(0xfffe), W(0x0f01), /* all 2.04-compliant and earlier */
5 - 1, /* 5 option vectors */
Index: linux-2.6-ozlabs/include/asm-powerpc/cputable.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/cputable.h
+++ linux-2.6-ozlabs/include/asm-powerpc/cputable.h
@@ -26,6 +26,7 @@
#define PPC_FEATURE_PA6T 0x0800
#define PPC_FEATURE_HAS_DFP0x0400
#define PPC_FEATURE_POWER6_EXT 0x0200
+#define PPC_FEATURE_ARCH_2_06 0x0100
Re: [PATCH 6/9] powerpc: Add VSX CPU feature
A couple of these lines originated with me.
Signed-off-by: Joel Schopp [EMAIL PROTECTED]
Michael Neuling wrote:
Add a VSX CPU feature. Also add code to detect if VSX is available
from the device tree.
Signed-off-by: Michael Neuling [EMAIL PROTECTED]
---
arch/powerpc/kernel/prom.c |3 +++
include/asm-powerpc/cputable.h | 13 +
2 files changed, 16 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/prom.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/prom.c
@@ -609,6 +609,9 @@ static struct feature_property {
{altivec, 0, CPU_FTR_ALTIVEC, PPC_FEATURE_HAS_ALTIVEC},
{ibm,vmx, 1, CPU_FTR_ALTIVEC, PPC_FEATURE_HAS_ALTIVEC},
#endif /* CONFIG_ALTIVEC */
+#ifdef CONFIG_VSX
+ {ibm,vmx, 2, CPU_FTR_VSX, PPC_FEATURE_HAS_VSX},
+#endif /* CONFIG_VSX */
#ifdef CONFIG_PPC64
{ibm,dfp, 1, 0, PPC_FEATURE_HAS_DFP},
{ibm,purr, 1, CPU_FTR_PURR, 0},
Index: linux-2.6-ozlabs/include/asm-powerpc/cputable.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/cputable.h
+++ linux-2.6-ozlabs/include/asm-powerpc/cputable.h
@@ -27,6 +27,7 @@
#define PPC_FEATURE_HAS_DFP0x0400
#define PPC_FEATURE_POWER6_EXT 0x0200
#define PPC_FEATURE_ARCH_2_06 0x0100
+#define PPC_FEATURE_HAS_VSX0x0080
#define PPC_FEATURE_TRUE_LE 0x0002
#define PPC_FEATURE_PPC_LE 0x0001
@@ -181,6 +182,7 @@ extern void do_feature_fixups(unsigned l
#define CPU_FTR_DSCR LONG_ASM_CONST(0x0002)
#define CPU_FTR_1T_SEGMENT LONG_ASM_CONST(0x0004)
#define CPU_FTR_NO_SLBIE_B LONG_ASM_CONST(0x0008)
+#define CPU_FTR_VSXLONG_ASM_CONST(0x0010)
#ifndef __ASSEMBLY__
@@ -199,6 +201,17 @@ extern void do_feature_fixups(unsigned l
#define PPC_FEATURE_HAS_ALTIVEC_COMP0
#endif
+/* We only set the VSX features if the kernel was compiled with VSX
+ * support
+ */
+#ifdef CONFIG_VSX
+#define CPU_FTR_VSX_COMP CPU_FTR_VSX
+#define PPC_FEATURE_HAS_VSX_COMP PPC_FEATURE_HAS_VSX
+#else
+#define CPU_FTR_VSX_COMP 0
+#define PPC_FEATURE_HAS_VSX_COMP0
+#endif
+
/* We only set the spe features if the kernel was compiled with spe
* support
*/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Power7 architected entry
Olof Johansson wrote: On Jun 18, 2008, at 3:18 PM, [EMAIL PROTECTED] wrote: Add an entry for Power7 architected mode and add (raw) to Power7 raw mode to distinguish it more clearly. Signed-off-by: Joel Schopp [EMAIL PROTECTED] --- arch/powerpc/kernel/cputable.c | 48 + arch/powerpc/platforms/pseries/cpu_setup.S |6 +++ include/asm-powerpc/cputable.h |9 + 3 files changed, 63 insertions(+) Huh? This patch only changes one file. -Olof The patch is correct, the shortlog is incorrect. Must not have gotten updated from an earlier version, sorry for the confusion. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] pseries: phyp dump: Variable size reserve space.
The aim is to have more flex space for the kernel on machines with more resources. Although the dump will be collected pretty fast and the memory released really early on allowing the machine to have the full memory available, this alleviates any issues that can be caused by having way too little memory on very very large systems during those few minutes. -Manish I think this would be an issue for distro kernels that have minimum requirements for memory above 256MB. It seems like a reasonable attempt to have good defaults. The user can always override it with boot args. I'm not sure where the exact numbers should be but the general statement that larger memory systems should have more memory to boot with seems like a good one. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/8] pseries: phyp dump: hypervisor-assisted dump
This looks like it is to a stable usable point now. In my opinion it is ready to be merged into the next tree for 2.6.26. Reviewed-by: Joel Schopp [EMAIL PROTECTED] Manish Ahuja wrote: Changes from previous version: The only changes are in patch 2. moved early_init_dt_scan_phyp_dump from rtas.c to phyp_dump.c Added dummy function in phyp_dump.h Patch 3 required repatching due to changes to patch 2. Resubmitting all patches to avoid confusion. Thanks, Manish Michael Ellerman wrote: On Sun, 2008-02-17 at 22:53 -0600, Manish Ahuja wrote: The following series of patches implement a basic framework for hypervisor-assisted dump. The very first patch provides documentation explaining what this is :-) . Yes, its supposed to be an improvement over kdump. A list of open issues / todo list is included in the documentation. It also appears that the not-yet-released firmware versions this was tested on are still, ahem, incomplete; this work is also pending. I have included most of the changes requested. Although, I did find one or two, fixed in a later patch file rather than the first location they appeared at. This series still doesn't build on !CONFIG_RTAS configs: http://kisskb.ellerman.id.au/kisskb/head/629/ This solution is to move early_init_dt_scan_phyp_dump() into arch/powerpc/platforms/pseries/phyp_dump.c and provide a dummy implementation in asm-powerpc/phyp_dump.c for the !CONFIG_PHYP_DUMP case. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: crash on shutdown on rs/6000 powerpc
[c0003f923c40] c003bff4 .xics_migrate_irqs_away+0x3c/0x20c [c0003f923d00] c0040d54 .pseries_cpu_disable+0x98/0xb4 [c0003f923d80] c0028e4c .__cpu_disable+0x44/0x58 [c0003f923df0] c007e204 .take_cpu_down+0x34/0x60 [c0003f923e70] c008ba3c .do_stop+0x144/0x1e4 [c0003f923f00] c006fd74 .kthread+0x78/0xc4 [c0003f923f90] c00272a8 .kernel_thread+0x4c/0x68 I don't have time tonight or tomorrow to track this down further. I'm taking the kids to the coast tommorow. :) This looks like the problem Olof and Milton sent out patches to fix. The Power3 shouldn't be doing cpu hotplug. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/2] powerpc: rmb fix
#define mb() __asm__ __volatile__ (sync : : : memory)
-#define rmb() __asm__ __volatile__ (__stringify(LWSYNC) : : : memory)
+#define rmb() __asm__ __volatile__ (sync : : : memory)
#define wmb() __asm__ __volatile__ (sync : : : memory)
#define read_barrier_depends() do { } while(0)
@@ -42,7 +42,7 @@
#ifdef __KERNEL__
#ifdef CONFIG_SMP
#define smp_mb() mb()
-#define smp_rmb()rmb()
+#define smp_rmb()__asm__ __volatile__ (__stringify(LWSYNC) : : :
memory)
#define smp_wmb()eieio()
#define smp_read_barrier_depends() read_barrier_depends()
#else
I had to think about this one for awhile. It looks at first glance to be the
right
thing to do. But I do wonder how long rmb() has been lwsync and if as a
practical
matter that has caused any problems? If this isn't causing any problems maybe
there
is some loigic we are overlooking?
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
