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
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
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
+ 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
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
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
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
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
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
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
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
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
---
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
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
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
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
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
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
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
+ 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
+
+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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
[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]
#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)
41 matches
Mail list logo
