[Openmcl-devel] Decreasing the size of the reserved heap

[David L. Rager]

At this point I've tried a couple things:

-- Setting MAP_NORESERVE (in pmcl-kernel.c) to 1 instead of 0.  This
resulted in an image that runs but still seems to allocate 128GB of
virtual memory.

-- Setting PURESPACE_RESERVE (in area.h) to 8G in the WORD_SIZE==64
case.  The lisp-kernel/linuxx8664 directory cleaned and built, but the
image has a signal 11 exception when run via scripts/ccl64.  This
isn't really surprising, as it's imaginable that more than one
constant needs to be changed.  Though, MANAGED_STATIC_SIZE is
calculated from PURESPACE_RESERVE, and that's what seems to be used to
allocate the reserved memory.

Thanks for the pointers to lisp-kernel/memory.c and MAP_NORESERVE, as
those were the starting points for finding these constants.

On Thu, Jan 9, 2014 at 12:44 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>
> On Jan 9, 2014, at 12:28 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
>
>> On 9 Jan 2014, at 16:12, Gary Byers wrote:
>>
>>> Gee, I don't remember ... I'd have to LOOK AT THE SOURCE, wouldn't I ?
>>
>> I apologise: I was being British and reticent (which I'm allowed to be, I am British and reticent) and not saying quite what I meant.  I had checked the source and noticed you're using MAP_NORESERVE, which I didn't know about previously.  MAP_NORESERVE worries me (not in the CCL context, in my day-job context) because it looks to me like it can be used to make systems which are otherwise safe, in the sense of `you always know who to blame when you run out of memory', not be so, unless the OS can be told to ignore it or there was some other subtlety I was missing which you knew about.
>>
>> And (this is now offtopic probably) I've just convinced myself after some reading that actually MAP_NORESERVE is OK, so long as the OS *does* reserve swap for people who don't use it (which I'm pretty sure is the case for Linux kernels now, with suitable configuration, anyway).  A shortfall can only happen due to an attempted allocation failing (in which case you know it's due to the allocation) or because one of the people who allocated with MAP_NORESERVE has touched too much memory.  In that case you don't know who to blame but you *do* know it wasn't someone who didn't use MAP_NORESERVE, so none of them will be wrongly blamed.
>
> Sorry if I'm restating an obvious point, but when CCL wants to use some of the address space that it mapped with MAP_NORESERVE, it changes that portion of the mapping (thereby causing actual VM consumption), and can signal an out-of-memory error if that remapping fails.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel