On 04/27/2013 12:30 AM, Helge Deller wrote: > * James Bottomley : >> On Wed, 2013-04-24 at 09:33 +0200, Helge Deller wrote: >>> On 04/23/2013 10:22 PM, Helge Deller wrote: >>>> commit e4e1e78facf7565cada909a69c7fb6415b6e7b83 >>>> Author: Helge Deller >>>> Date: Tue Apr 23 17:19:37 2013 +0200 >>>> >>>> parisc: increase kernel stack size to 32k >>>> >>>> --- a/arch/parisc/include/asm/thread_info.h >>>> +++ b/arch/parisc/include/asm/thread_info.h >>>> -#define THREAD_SIZE_ORDER 2 >>>> +#define THREAD_SIZE_ORDER 3 /* 32k stack */ >>> >>> I tested again, and it actually needs to be 64k stacks to not crash any longer. >>> So, the right temporary fix is: >>> >>>> +#define THREAD_SIZE_ORDER 4 /* 64k stack */ >>> >>> Will send updated patch soon. >> >> This is an indicator of something seriously wrong somewhere. We've >> always had the 16k stack just because of our large frames. In theory, >> the IRQ stack should only be the same size as the kernel stack, so if we >> have both in the same place, we should only need at max 32k ... if we're >> still seeing problems related to stack overrun, then it might be we have >> an IRQ recursion where we shouldn't have. To be honest, I have a hard >> time explaining why our stacks should be over 8k. Attached is a new version of my irq-stack-patch, which made my system really stable :-) As test I did used "hackbench 300" (from the LTP project) which created 12000 threads: uptime: 23:44:09 up 17 min, 2 users, load average: 1232.23, 2966.09, 2466.39 My findings so far: * kernel stack: THREAD_SIZE_ORDER needs to be at least 2 (=16k). x86 has 1 (8k). With 8k kernel stacks and DEBUG_STACKOVERFLOW enabled, I get directly after bootup: stackcheck: swapper/0 has overflown a kernel stack (sp:bfc52030, stk bottom-top:bfc50000-bfc52000) * IRQ stack: 16k seems sufficient as well. So, the combination of 16k kernel stack and 16k irq stacks seems OK. I still need to clean up my patch, test if backtraces still work (with which I currently have problems) and prepare a final patch. Helge