Re: [PATCH] parisc: increase kernel stack size to 32k

John David Anglin
2013-04-27T23:09:15Z

On 27-Apr-13, at 5:53 PM, Helge Deller wrote:

> On 04/27/2013 12:30 AM, Helge Deller wrote:
>> * James Bottomley <James.Bottomley@HansenPartnership.com>:
>>> 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 <deller@gmx.de>
>>>>> 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.

So far, I haven't been able to break the first version of the irqstack
patch. It's working far better than
setting THREAD_SIZE_ORDER to 4. There were various application errors
with the latter. Building
new version.

I have the following comments:

+#define get_current_sp(sp) __asm__("copy %%r30, %0" : "=r"(sp))

Probably, should be __asm__ __volatile__. I'm not sure that all changes
to the stack pointer are known to GCC.

+/* void call_on_stack(unsigned long param1, void *func, unsigned long
new_stack) */
+ENTRY(call_on_stack)
+ STREG %sp, 8(%arg2)
+ STREG %rp, 16(%arg2)
+
+ /* HPPA calling convention for function pointers */
+#ifdef CONFIG_64BIT
+ LDREG 16(%arg1), %arg1
+ bve,l (%arg1), %rp
+ addi 0x40, %arg2, %sp
+#else
+ addi 0x40, %arg2, %sp
+ be,l 0(%sr4,%arg1), %sr0, %r31
+ copy %r31, %rp
+#endif
+
+ addi -0x40, %sp, %sp
+ LDREG 16(%sp),%rp
+ bv (%rp)
+ LDREG 8(%sp),%sp
+ENDPROC(call_on_stack)

This doesn't full adhere to calling conventions but may work in
limited circumstances. For
example, 64-bit calls nominally require setup of the argument
pointer. There's also save
and restore of the PIC register if it can be modified.

Dave
--
John David Anglin dave.anglin@bell.net