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

Re: [MirageOS-devel] Memory exhaustion in Mirage



Not at the moment, although we could easily add an explicit deallocator into
Io_page.  You need to very careful that the page is not used after its lifetime,
so more pool-based abstractions are preferred (where the pages are recycled into
an OCaml-managed data structure and reused rather than GCed).

You should be able to pump up the amount of RAM the VM gets temporarily to 4GB
or so -- if the page allocator still remains low, then it's unlikely to be a GC
issue and an actual leak somewhere due to holding onto references and keeping
the page live.

-anil

> On 18 Dec 2014, at 05:41, Masoud Koleini <masoud.koleini@xxxxxxxxxxxxxxxx> 
> wrote:
> 
> Is it possible to deallocate an Io_page after packet is send, not to wait for 
> GC?
> 
> On 16/12/14 23:45, Anil Madhavapeddy wrote:
>> On 16 Dec 2014, at 15:23, Masoud Koleini <masoud.koleini@xxxxxxxxxxxxxxxx> 
>> wrote:
>>> I am wondering if the following issue is already addressed:
>>> 
>>> https://github.com/mirage/mirage-tcpip/issues/33
>>> 
>>> https://lists.cam.ac.uk/pipermail/cl-mirage/2013-August/msg00104.html
>>> 
>> It probably still happens at 64MB of RAM -- it requires some code to adjust
>> the GC parameters in the OCaml runtime to trigger a collection more often.
>> It should be harmless however, since (as the bug report observes), a failure
>> to allocate an Io_page results in a GC compaction that frees up memory so
>> that the allocation eventually succeeds.
>> 
>> Any particular reason for asking -- is the bug affecting your switch somehow?
>> 
>> -anil
> 
> 
> 
> 
> 
> This message and any attachment are intended solely for the addressee and may 
> contain confidential information. If you have received this message in error, 
> please send it back to me, and immediately delete it.   Please do not use, 
> copy or disclose the information contained in this message or in any 
> attachment.  Any views or opinions expressed by the author of this email do 
> not necessarily reflect the views of the University of Nottingham.
> 
> This message has been checked for viruses but the contents of an attachment 
> may still contain software viruses which could damage your computer system, 
> you are advised to perform your own checks. Email communications with the 
> University of Nottingham may be monitored as permitted by UK legislation.
> 


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


 


Rackspace

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