On Jun 16, 2012, at 12:45 AM, Janne Johansson <icepic...@gmail.com> wrote:
> 2012/6/15 Bryan Irvine <sparcta...@gmail.com>: >> On Fri, Jun 15, 2012 at 2:15 AM, Janne Johansson <icepic...@gmail.com> wrote: >>> The ulimits will ultimately be capped by the platform MAXDSIZ, which >>> for mipses probably is 1G: >>> >>> ./arch/mips64/include/vmparam.h:#define MAXDSIZ >>> (1*1024*1024*1024) /* max data size */ >>> >>> ..so that's where "ulimit -d unlimited" will allow at most. >> >> Ah, that explains why messing with ulimit didn't seem to make any difference. >> >> Would adjusting that help me in this case? > > Can't say. One thing for sure is that the limits are there to make > sure small-mem systems (32-bits CPUs) dont have their kernel, stack, > heap, libs and memorymapped I/O areas overlap for any program. Perhaps > you can up it a bit perhaps not, best way would be to try. > > There is a neat dungeon of stuff to read and learn in order to figure > out what the maximum size for any given platform would be and how it > affects max stack size, brk() sizes and what not. You are likely to be > eaten by a grue. =) Many many grues! I kind of tried a few experiments. Most of them ended badly the rest didn't affect anything at all. *sigh*
