On Aug 22, 2013, at 1:20 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > >> This issue comes up occasionally. Should we consider having a PETSc >> option that uses setrlimit() to bound the virtual memory size the >> process can have? Not a perfect solution but at least something, >> maybe better than nothing? > > Nah, just use mlock() so that PETSc's pages are always resident. Let > mlock fail or the OS kill us This is part of the "problem", if the OS kills the code (at some "random" time when memory runs low) then users are very confused. In my reading of setrlimit() malloc will fail and this gives good feedback to the user as opposed to "random crashes". Barry The system refuses to extend the data or stack space when the limits would be exceeded in the normal way: a break call fails if the data space limit is reached. When the stack limit is reached, the process receives a segmentation fault (SIGSEGV); if this signal is not caught by a handler using the signal stack, this signal will kill the process. It is not perfect because running out of stack space still generates a segv, but stack space is usually not an issue in PETSc runs, running out of heap is the problem. > when there's not enough memory.
