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/