From: John David Anglin <dave.anglin@bell.net>
To: Helge Deller <deller@gmx.de>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
linux-parisc@vger.kernel.org
Subject: Re: [PATCH] parisc: increase kernel stack size to 32k
Date: Sat, 27 Apr 2013 19:09:15 -0400 [thread overview]
Message-ID: <BLU0-SMTP100ADB80BC8ECEF0AB6F92A97B00@phx.gbl> (raw)
In-Reply-To: <517C48E7.7050701@gmx.de>
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
prev parent reply other threads:[~2013-04-27 23:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 20:22 [PATCH] parisc: increase kernel stack size to 32k Helge Deller
2013-04-24 7:33 ` Helge Deller
2013-04-24 20:41 ` James Bottomley
2013-04-26 22:30 ` Helge Deller
2013-04-27 21:53 ` Helge Deller
2013-04-27 23:09 ` John David Anglin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU0-SMTP100ADB80BC8ECEF0AB6F92A97B00@phx.gbl \
--to=dave.anglin@bell.net \
--cc=James.Bottomley@HansenPartnership.com \
--cc=deller@gmx.de \
--cc=linux-parisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.