[ppc] Default stack size on ppc64

[Steven Munroe]

On Thu, 2015-03-26 at 09:50 +0000, David Woodhouse wrote:
> On Thu, 2015-03-26 at 08:57 +0000, Richard W.M. Jones wrote:
> > Is pthread_create used even for the main thread in the process (I
> > thought the kernel created that).  In any case threads aren't being
> > used explicitly by this process.
> > 
> > Anyway I guess the guard page is just a hole that causes the process
> > to abort (as observed) and is not a mechanism for automatically
> > growing the stack.
> 
> Right, It's a mechanism for catching stack overflow reliably, rather 
> than letting it cause random memory corruption.
> 
> But for the original stack created by the kernel when the process is 
> created, I think you just don't have the guard page. All that stops 
> you is the ulimit.
> 
As David mentions the original stack is created by the kernel (along
with the argv, env, and auxv for process) in high virtual.

3fff8cd30000-3fff8cd50000 r-xp 00000000 00:00 0  [vdso]
3fff8cd50000-3fff8cd80000 r-xp 00000000 08:00
12456160                   /lib/powerpc64le-linux-gnu/ld-2.19.so
3fff8cd80000-3fff8cd90000 rw-p 00020000 08:02
12456160                   /lib/powerpc64le-linux-gnu/ld-2.19.so
3fffd0df0000-3fffd0e20000 rw-p 00000000 00:00 0  [stack]

Changing the ulimit (-s) effects the space left between the top of the
address space and where the kernel loads the dynamic linker (ld.so). For
example with unlimit -s 16384:

3fffae380000-3fffae3a0000 r-xp 00000000 00:00 0  [vdso]
3fffae3a0000-3fffae3d0000 r-xp 00000000 08:02
12456160                   /lib/powerpc64le-linux-gnu/ld-2.19.so
3fffae3d0000-3fffae3e0000 rw-p 00020000 08:02
12456160                   /lib/powerpc64le-linux-gnu/ld-2.19.so
3ffff1a10000-3ffff1a40000 rw-p 00000000 00:00 0  [stack]

It also effects the allocation of thread stacks (GLIBC uses getrlimit()
then uses that value to allocate the thread stacks.

3fffaa160000-3fffab150000 rw-p 00000000 00:00 0  [stack: 29163]
3fffab150000-3fffab160000 ---p 00000000 00:00 0
3fffab160000-3fffac150000 rw-p 00000000 00:00 0
3fffac150000-3fffac160000 ---p 00000000 00:00 0
3fffac160000-3fffad150000 rw-p 00000000 00:00 0
3fffad150000-3fffad160000 ---p 00000000 00:00 0
3fffad160000-3fffae150000 rw-p 00000000 00:00 0


> So... we could potentially look for ways to reduce the stack usage of 
> OCaml-compiled code, or you get to keep increasing the limit.
> 
> It might be worth taking a look at the stack frames and seeing if I 
> did anything entirely stupid when setting them up, and whether they 
> can be made smaller. Although if you said it was averaging ~168 bytes, 
> that doesn't seem *particularly* excessive. Can you see how big the 
> stack actually does get in your worst case, and how much we'd have to 
> shrink by in order to get away without tweaking the ulimit?
> 
> Perhaps we could also look at using a smaller stack frame between 
> OCaml functions. If we're never using certain registers in the OCaml 
> code generator, we don't need to save them or leave space for them on 
> the stack. All we need to do it ensure that if we're calling out to a C
> function, we *do* leave enough space in the stack frame for callee-
> saved registers, right?
> 
> I concede to being a bit rusty here... :)
>