[PATCH] powerpc: reset kernel stack on cpu online from cede state
powerpc: reset kernel stack on cpu online from cede state
Cpu hotplug (offline) without dlpar operation will place cpu
in cede state and the extended_cede_processor() function will
return when resumed.
Kernel stack pointer needs to be reset before
start_secondary() is called to continue the online operation.
Added new function start_secondary_resume() to do the above
steps.
Signed-off-by: Vaidyanathan Srinivasan sva...@linux.vnet.ibm.com
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 9258074..567cd57 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -615,6 +615,17 @@ _GLOBAL(start_secondary_prolog)
std r3,0(r1)/* Zero the stack frame pointer */
bl .start_secondary
b .
+/*
+ * Reset stack pointer and call start_secondary
+ * to continue with online operation when woken up
+ * from cede in cpu offline.
+ */
+_GLOBAL(start_secondary_resume)
+ ld r1,PACAKSAVE(r13) /* Reload kernel stack pointer */
+ li r3,0
+ std r3,0(r1)/* Zero the stack frame pointer */
+ bl .start_secondary
+ b .
#endif
/*
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c
b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 6ea4698..9be7af4 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -146,12 +146,11 @@ static void pseries_mach_cpu_die(void)
unregister_slb_shadow(hwcpu, __pa(get_slb_shadow()));
/*
-* NOTE: Calling start_secondary() here for now to
-* start new context.
-* However, need to do it cleanly by resetting the
-* stack pointer.
+* Call to start_secondary_resume() will not return.
+* Kernel stack will be reset and start_secondary()
+* will be called to continue the online operation.
*/
- start_secondary();
+ start_secondary_resume();
} else if (get_preferred_offline_state(cpu) == CPU_STATE_OFFLINE) {
diff --git a/arch/powerpc/platforms/pseries/offline_states.h
b/arch/powerpc/platforms/pseries/offline_states.h
index 22574e0..da07256 100644
--- a/arch/powerpc/platforms/pseries/offline_states.h
+++ b/arch/powerpc/platforms/pseries/offline_states.h
@@ -14,5 +14,5 @@ extern void set_cpu_current_state(int cpu, enum
cpu_state_vals state);
extern enum cpu_state_vals get_preferred_offline_state(int cpu);
extern void set_preferred_offline_state(int cpu, enum cpu_state_vals state);
extern void set_default_offline_state(int cpu);
-extern int start_secondary(void);
+extern void start_secondary_resume(void);
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
Hi David, On Wed, 17 Feb 2010 15:55:27 +0100 Anatolij Gustschin ag...@denx.de wrote: These patches attempt to provide support for the Freescale MPC512x FEC in the fs_enet driver. The first cleanup patch replaces printk by dev_xxx. The second and third attemt to support MPC5121 FEC in the FEC driver. Could you please comment on this patch series. The patches have been acked by Grant and I slightly reworked third patch to address Eric's comments, so there is v3 for this patch now. Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [net-next-2.6 PATCH v2 0/3] Support for MPC512x FEC
From: Anatolij Gustschin ag...@denx.de Date: Mon, 22 Feb 2010 12:37:24 +0100 Could you please comment on this patch series. It's in the net-next-2.6 tree. If you need to make any more changes, they need to be relative to what went into my tree. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: default stack size for threads changed
Joakim Tjernlund/Transmode wrote on 2010/02/22 13:20:12: With current, 2.6.33-rc6, linux the default stack size changed from unlimited to 8MB: # ulimit -s 8192 This makes NPTL allocate a 8MB stack for each thread that is created. This breaks in our embedded system. Although this can be fixed in our app I wonder if this is intentional? Jocke Forgot to mention that timer_create(2) increases the stack with 8MB too. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target symbol */
+ int type;
+ char*name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+};
I don't think it's a good idea to integrate the name of
the target. This is something that should be done in a higher
level, not in an arch backend.
We don't even need to store it anywhere as we can resolve
back an address easily. Symbol awareness is not something
the hardware breakpoint should care about, neither in the
arch nor the generic level.
The 'name' field here is actually a legacy inherited from x86 code. It
is part of x86's arch-specific hw-breakpoint structure since:
- inspired by the kprobe implementation which accepts symbol name as
input.
- kallsyms_lookup_name() was 'unexported' and a module could not resolve
symbol names externally, so the core-infrastructure had to provide
such facilities.
- I wasn't sure about the discussions behind 'unexporting' of
kallsyms_lookup_name(), so did not venture to export them again (which
you rightfully did :-)
Having said that, I'll be glad to remove this field (along with that in
x86), provided we know that there's a way for the user to resolve symbol
names on its own i.e. routines like kallsyms_lookup_name() will remain
exported.
Also, do you think addr/len/type is enough to abstract out
any ppc breakpoints?
This looks enough to me to express range breakpoints and
simple breakpoints. But what about value comparison?
(And still, there may be other trickier implementations
I don't know in ppc).
The above implementation is for PPC64 architecture that supports only
'simple' breakpoints of fixed length (no range breakpoints, no value
comparison). More on that below.
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm/system.h
+
+/* Total number of available HW breakpoint registers */
+#define HBP_NUM 1
Looking at the G2 PowerPc implementation, DABR and DABR2 can either
express two different watchpoints or one range watchpoint.
There are also IABR and IABR2 for instruction breakpoints that
follow the same above scheme. I'm not sure we can abstract that
using a constant max linear number of resources.
As stated above, the patch implements breakpoints for PPC64 processors
only (http://www.power.org/resources/downloads/PowerISA_V2.06_PUBLIC.pdf),
which does not support advanced breakpoint features (which its ppc
Book-E counterpart has).
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
So, this is only about data breakpoints?
Yes, newer PPC64 processors do not support IABR.
+ /*
+* As a policy, the callback is invoked in a 'trigger-after-execute'
+* fashion
+*/
+ (bp-overflow_handler)(bp, 0, NULL, regs);
Why are you calling this explicitly instead of using the perf_bp_event()
thing? This looks like it won't work with perf as the event won't
be recorded by perf.
Yes, should have invoked perf_bp_event() for perf to work well (on a
side note, it makes me wonder at the amount of 'extra' code that each
breakpoint exception would execute if it were not called through perf
sys-call...well, the costs of integrating with a generic infrastructure!)
+void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs)
+{
+ struct perf_event_attr attr;
+
+ /*
+* Disable the breakpoint request here since ptrace has defined a
+* one-shot behaviour for breakpoint exceptions in PPC64.
+* The SIGTRAP signal is generated automatically for us in do_dabr().
+* We don't have to do anything about that here
+*/
Oh, why does ptrace use a one-shot behaviour in ppc? Breakpoints
only trigger once?
Yes, ptrace breakpoints on PPC64 are designed to trigger once and this
patch retains that behaviour. It is very convenient to use one-shot
behaviour on archs where exceptions are triggered-before-execute.
+ if (bp) {
+ attr = bp-attr;
+ attr.bp_addr = data ~HW_BREAKPOINT_ALIGN;
+
+ switch (data (DABR_DATA_WRITE | DABR_DATA_READ)) {
+ case DABR_DATA_READ:
+ attr.bp_type = HW_BREAKPOINT_R;
+ break;
+ case DABR_DATA_WRITE:
+ attr.bp_type = HW_BREAKPOINT_W;
+ break;
+ case (DABR_DATA_WRITE | DABR_DATA_READ):
+ attr.bp_type = HW_BREAKPOINT_R | HW_BREAKPOINT_W;
+ break;
+ }
+ ret = modify_user_hw_breakpoint(bp, attr);
+ if (ret)
+ return ret;
+ thread-ptrace_bps[0] = bp;
+ thread-dabr = data;
+
Re: [PATCH] powerpc/mpc512x: Add gpio driver
Hi Grant, thanks for comments. I will post an updated version soon. On Tuesday 16 February 2010 20:19, Grant Likely wrote: + return 0; +} +arch_initcall(mpc512x_add_gpiochips); Don't do this. Either make this a proper of_platform device driver, or call mpc512x_add_gpiochips() explicitly from the arch platform setup code. Otherwise, if the kernel is built for multiplatform, this function will get executed regardless of the platform. In this case I prefer moving the call to the platform code. I tested the driver on one of our 5123 boards. Shall I add it to mpc5121_ads.c:mpc5121_ads_setup_arch() also? So it's at least called on the reference board? I not sure if there are some LEDs or buttons that could use it. Matthias ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc512x: Add gpio driver
On Mon, Feb 22, 2010 at 9:05 AM, Matthias Fuchs matthias.fu...@esd-electronics.com wrote: Hi Grant, thanks for comments. I will post an updated version soon. On Tuesday 16 February 2010 20:19, Grant Likely wrote: + return 0; +} +arch_initcall(mpc512x_add_gpiochips); Don't do this. Either make this a proper of_platform device driver, or call mpc512x_add_gpiochips() explicitly from the arch platform setup code. Otherwise, if the kernel is built for multiplatform, this function will get executed regardless of the platform. In this case I prefer moving the call to the platform code. I tested the driver on one of our 5123 boards. Shall I add it to mpc5121_ads.c:mpc5121_ads_setup_arch() also? So it's at least called on the reference board? I not sure if there are some LEDs or buttons that could use it. Yes, make sure all 5121 platforms call it. Thanks, g. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] backlight: mark struct backlight_ops const
On Sat, Feb 20, 2010 at 18:18, Bruno Prémont wrote: drivers/video/bf54x-lq043fb.c | 2 +- drivers/video/bfin-t350mcqb-fb.c | 2 +- Acked-by: Mike Frysinger vap...@gentoo.org -mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [async_tx-next PATCH 2/2] fsldma: Fix cookie issues
On Mon, 22 Feb 2010, Steven J. Magnani wrote: diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h --- a/include/linux/dmaengine.h 2010-02-22 11:18:11.0 -0600 +++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.0 -0600 @@ -31,6 +31,8 @@ * if dma_cookie_t is 0 it's a DMA request cookie, 0 it's an error code */ typedef s32 dma_cookie_t; +#define DMA_MIN_COOKIE 1 +#define DMA_MAX_COOKIE 2147483647 Taking into account, that dma_cookie_t is 32 bits: +#define DMA_MAX_COOKIE ((1 31) - 1) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[async_tx-next PATCH 2/2] fsldma: Fix cookie issues
fsl_dma_update_completed_cookie() appears to calculate the last completed
cookie incorrectly in the corner case where DMA on cookie 1 is in progress
just following a cookie wrap.
Signed-off-by: Steven J. Magnani st...@digidescorp.com
---
diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
--- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.0 -0600
+++ b/drivers/dma/fsldma.c 2010-02-22 11:08:41.0 -0600
@@ -819,8 +819,11 @@ static void fsl_dma_update_completed_coo
desc = to_fsl_desc(chan-ld_running.prev);
if (dma_is_idle(chan))
cookie = desc-async_tx.cookie;
- else
+ else {
cookie = desc-async_tx.cookie - 1;
+ if (unlikely(cookie DMA_MIN_COOKIE))
+ cookie = DMA_MAX_COOKIE;
+ }
chan-completed_cookie = cookie;
diff -uprN a/include/linux/dmaengine.h b/include/linux/dmaengine.h
--- a/include/linux/dmaengine.h 2010-02-22 11:18:11.0 -0600
+++ b/include/linux/dmaengine.h 2010-02-22 11:18:30.0 -0600
@@ -31,6 +31,8 @@
* if dma_cookie_t is 0 it's a DMA request cookie, 0 it's an error code
*/
typedef s32 dma_cookie_t;
+#define DMA_MIN_COOKIE 1
+#define DMA_MAX_COOKIE 2147483647
#define dma_submit_error(cookie) ((cookie) 0 ? 1 : 0)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[async_tx-next PATCH 0/2] fsldma: Fix cookie issues
In modeling a new DMA engine on the FSL code, I ran across what look to be some bugs in FSL cookie handling. As I don't have FSL HW or even a PPC, I can't verify the problem or the fix, but I did ensure that the changes compile. BTW thanks to all involved in creation of the FSL driver, it's a nice model to follow. Regards, Steven J. Magnani I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator! #include standard.disclaimer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[async_tx-next PATCH 1/2] fsldma: Fix cookie issues
fsl_dma_tx_submit() only sets the cookie on the first descriptor of a transaction. It should set the cookie on all. Signed-off-by: Steven J. Magnani st...@digidescorp.com --- diff -uprN a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c --- a/drivers/dma/fsldma.c 2010-02-22 11:16:36.0 -0600 +++ b/drivers/dma/fsldma.c 2010-02-22 11:24:01.0 -0600 @@ -362,7 +362,7 @@ static dma_cookie_t fsl_dma_tx_submit(st if (cookie 0) cookie = 1; - desc-async_tx.cookie = cookie; + child-async_tx.cookie = cookie; } chan-common.cookie = cookie; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
On Wed, 17 Feb 2010 13:19:52 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: No functional change; this breaks up pci_read_bridge_bases() into separate pieces for the I/O, memory, and prefetchable memory windows, similar to how Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc. Signed-off-by: Bjorn Helgaas bjorn.helg...@hp.com --- Applied this series, thanks Bjorn. Hopefully this one will successfully run the linux-next gauntlet too. :) -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/5] PCI: split up pci_read_bridge_bases()
On Wed, 17 Feb 2010 13:19:52 -0700 Bjorn Helgaas bjorn.helg...@hp.com wrote: No functional change; this breaks up pci_read_bridge_bases() into separate pieces for the I/O, memory, and prefetchable memory windows, similar to how Yinghai recently split up pci_setup_bridge() in 68e84ff3bdc. Signed-off-by: Bjorn Helgaas bjorn.helg...@hp.com --- Had to drop these again, got: Kernel: arch/x86/boot/bzImage is ready (#16) MODPOST 2245 modules ERROR: pci_bus_resource_n [drivers/pcmcia/yenta_socket.ko] undefined! ERROR: pci_bus_resource_n [drivers/pcmcia/rsrc_nonstatic.ko] undefined! ERROR: pci_bus_resource_n [drivers/pci/hotplug/shpchp.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 when building. -- Jesse Barnes, Intel Open Source Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
Hi Balbir, A reclaim distance of 10 implies a ratio of 1, that means we'll always do zone_reclaim() to free page cache and slab cache before moving on to another node? I want to make an effort to reclaim local pagecache before ever going off node. As an example, a completely off node stream result is almost 3x slower than on node on my test box. Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
Hi Sean: I will withdraw this patch. I had a talk with the U-Boot guys. The reason for this patch was to support those guys that had their ECC ordering at (213) on the older version of the kernel. Upgrading to (123) may be problematic. Since without a jtag it would be a bit complex. I still think this NAND_ECC_SMC define is somewhat missleading. Given that both 1-2-3 and 2-1-3 are supported by the correction routine. Feng From: Sean MacLennan [mailto:smaclen...@pikatech.com] Sent: Sat 2/20/2010 5:11 PM To: Feng Kan Cc: linux-...@lists.infradead.org; linuxppc-...@ozlabs.org; Feng Kan Subject: Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc On Thu, 18 Feb 2010 15:11:18 -0800 Feng Kan f...@amcc.com wrote: This is to lock down the ordering in the correction routine against the calculate routine. Otherwise, incorrect define would cause ECC errors. Did you actually find a 44x PPC core that is not NAND_ECC_SMS format? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
On Mon, 22 Feb 2010 21:21:53 -0800 Feng Kan f...@amcc.com wrote: Hi Sean: I will withdraw this patch. I had a talk with the U-Boot guys. The reason for this patch was to support those guys that had their ECC ordering at (213) on the older version of the kernel. Upgrading to (123) may be problematic. Since without a jtag it would be a bit complex. I still think this NAND_ECC_SMC define is somewhat missleading. Given that both 1-2-3 and 2-1-3 are supported by the correction routine. The 213 ordering is my fault. I changed it to match what u-boot did rather than keeping the order from the old arch-ppc driver. Believe me, I have been raked over the coals at work for this :( I agree the NAND_ECC_SMC is misleading. The NAND_ECC_SMC *is* correct. The confusion is that the SMC is handled later on, so you must keep the byte order unaltered in this routine. I wrote a simple driver that allows you to boot with the old kernel, insmod the driver, burn new images (including a kernel with the correct byte order!), and then reboot into the new kernel. If anybody wants this, just ask. It will take a little work to get it working with other NANDs since it needs to know the NAND name to get the mtd structure. It also assumes you have a way to write to NAND in user mode. The mtd-utils flash_eraseall and nandwrite are good enough. Cheers, Sean ___ 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
In message 24165.1266577...@neuling.org you wrote:
In message 1266573672.1806.70.ca...@laptop you wrote:
On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
include/linux/sched.h |2 +-
kernel/sched_fair.c | 61 +
++
++--
-
2 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 0eef87b..42fa5c6 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -849,7 +849,7 @@ enum cpu_idle_type {
#define SD_POWERSAVINGS_BALANCE0x0100 /* Balance for power sa
vings */
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing
instanc
e */
-
+#define SD_ASYM_PACKING0x0800
Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
or is this ok to add it generically?
I'd think we'd want to keep that limited to architectures that actually
need it.
OK
+static int update_sd_pick_busiest(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ struct sched_group *sg,
+ struct sg_lb_stats *sgs)
+{
+ if (sgs-sum_nr_running sgs-group_capacity)
+ return 1;
+
+ if (sgs-group_imb)
+ return 1;
+
+ if ((sd-flags SD_ASYM_PACKING) sgs-sum_nr_running) {
+ if (!sds-busiest)
+ return 1;
+
+ if (group_first_cpu(sds-busiest) group_first_cpu(gro
up))
group = sg here? (I get a compile error otherwise)
Oh, quite ;-)
+static int check_asym_packing(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ int cpu, unsigned long *imbalance)
+{
+ int i, cpu, busiest_cpu;
Redefining cpu here. Looks like the cpu parameter is not really needed?
Seems that way indeed, I went back and forth a few times on the actual
implementation of this function (which started out live as a copy of
check_power_save_busiest_group), its amazing there were only these two
compile glitches ;-)
:-)
Below are the cleanups + the arch specific bits. It doesn't change your
logic at all. Obviously the PPC arch bits would need to be split into a
separate patch.
Compiles and boots against linux-next.
I have some comments on the code inline but...
So when I run this, I don't get processes pulled down to the lower
threads. A simple test case of running 1 CPU intensive process at
SCHED_OTHER on a machine with 2 way SMT system (a POWER6 but enabling
SD_ASYM_PACKING). The single processes doesn't move to lower threads as
I'd hope.
Also, are you sure you want to put this in generic code? It seem to be
quite POWER7 specific functionality, so would be logically better in
arch/powerpc. I guess some other arch *might* need it, but seems
unlikely.
Mikey
---
arch/powerpc/include/asm/cputable.h |3 +
arch/powerpc/kernel/process.c |7 +++
include/linux/sched.h |4 +-
include/linux/topology.h|1
kernel/sched_fair.c | 64 +
+--
5 files changed, 74 insertions(+), 5 deletions(-)
Index: linux-next/arch/powerpc/include/asm/cputable.h
===
--- linux-next.orig/arch/powerpc/include/asm/cputable.h
+++ linux-next/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAO LONG_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_ASYM_SMT4LONG_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_ASYM_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 | \
Index: linux-next/arch/powerpc/kernel/process.c
===
--- linux-next.orig/arch/powerpc/kernel/process.c
+++ linux-next/arch/powerpc/kernel/process.c
@@ -1265,3 +1265,10 @@ unsigned long randomize_et_dyn(unsigned
return ret;
}
+
+int arch_sd_asym_packing(void)
+{
Re: default stack size for threads changed
Michael Neuling mi...@neuling.org wrote on 2010/02/23 02:58:16: In message OF21CCB5A6.CDFDB6C1-ONC12576D2.00430B25-C12576D2. 0043c...@transmode.se you wrote: With current, 2.6.33-rc6, linux the default stack size changed from unlimited to 8MB: # ulimit -s 8192 This makes NPTL allocate a 8MB stack for each thread that is created. This breaks in our embedded system. Although this can be fixed in our app I wonder if this is intentional? When did this change from unlimited? Sometime after 2.6.30 since that was the previous kernel we used, but I see now that I read the wrong line. The stack size was 8MB in 2.6.30 too so something else caused the high stack usage. It's unlikely but this might be related 803bf5ec259941936262d10ecc84511b76a20921 (post rc7). You'll also need to grab this http://patchwork.kernel.org/patch/79365/. I see, will try. Hope fully I will see an improvement. Thanks. Mikey Jocke ___ 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
