[ppc] Default stack size on ppc64

Richard W.M. Jones rjones at redhat.com
Wed Mar 25 19:37:28 UTC 2015


On Wed, Mar 25, 2015 at 06:30:25PM +0000, David Woodhouse wrote:
> On Tue, 2015-03-24 at 11:35 -0500, Steven Munroe wrote:
> > I am not sure how ocaml is generating code for PPC64, you could look in
> > to split stack support, but at this time GCC does not implement split
> > stack.
>          ... for PPC64.
> 
> I wouldn't want to do it in OCaml before it's supported in GCC and the 
> runtime. But once it *is*, it shouldn't be hard to make OCaml support 
> it.
> 
> It's mostly just a matter of emitting the right instructions in the 
> function prologue and epilogue, in emit.mlp.
> 
> But it does depend on the runtime support for allocating more stack 
> while not overflowing the 'slop' space on the existing stack, and 
> linker support for expanding the stack frame size when calling through 
> to legacy non-split-stack functions, and probably other things. So not 
> something we'd want to do purely within OCaml.
> 
> I'm a little confused about what the problem is, though.

In summary: when you run ocamlopt to compile a sufficiently
complicated OCaml program, ocamlopt segfaults.  We found the cure is
to do 'ulimit -s 65536' before running ocamlopt.

> If the compiler is single-threaded, and increasing the stack ulimit 
> fixes the problem, that implies that the default stack ulimit is less 
> than the 8MiB-64KiB that it takes to reach the guard page... can that 
> be right? Richard, what does 'ulimit -s' report *before* you increase 
> it?

$ ulimit -s
8192

(For reference, all the limits are attached below).

That is from Fedora 20 ppc64 (not -le).  The server is a POWER 7
LPAR.  The page size is 64K.

I don't currently have access to a newer Fedora machine, but the same
segfault was reported in current Rawhide and it was cured in the same
way, so it seems unlikely that the default stack size is different there.

Rich.

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 496059
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/


More information about the devel mailing list