[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mirage/kFreeBSD on GitHub

On 5 Aug 2012, at 00:30, PALI Gabor Janos <pgj@xxxxxxx> wrote:

> On Sun, Aug 05, 2012 at 12:47:57AM +0200, PALI Gabor Janos wrote:
>> Perhaps the rest of the kernel is just simply too busy with allocating the
>> requested memory?
> Yeah, technically all the physical memory is consumed by the module at the
> point of hanging.
> db> show malloc
>              Type         InUse          MemUse     Requests
>            mirage           967         923430K          976
>           ...
> (The machine has 1 GB RAM.)
> Anil: what should be the expected behavior of the garbage collector?

The OCaml GC will malloc() memory to grow heap chunks.  It does this in 
configurable increments [1], specifically via the major_heap_increment

For a stress test where the working size is small, but the garbage collected
is large (as with the looping-string-alloc test), you want to tweak these
variables such that the GC will run collections much more often (the
space_overhead setting), and minimise wastage of memory.  This will keep the
working set of allocated memory small, and keep the kernel module running
in a fairly steady state.

If the OCaml heap *does* try to grow via a malloc and it fails, there is no
easy recovery, and an Out_of_memory exception will be raised.  This is usually
fairly fatal for the process and ought to be avoided.

[1] OCAMLRUNPARAM variables in 




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.