On Fri, Jul 15, 2016 at 8:39 PM, Antti Kantee <[email protected]> wrote: > On 15/07/16 13:23, Neeraj Sharma wrote: >> >> As anticipated Erlang >> VM is requesting for larger chunk 1GB of memory while VM is running >> 256MB which surprisingly goes into an infinite loop within rumprun. >> >> I have raised an issue https://github.com/rumpkernel/rumprun/issues/81 >> to track the same and will be great if it's looked at. > > > ic. Well, that doesn't really seem too hard to fix, especially on the > Erlang VM side. It's a classic case of "we're running on top of virtual > memory, so let's just allocate silly amounts". >
I agree that application should be updated (at some point) to understand the operating system it is running although rumprun does make initial porting effort much easier. Having said that I believe it will be easier (for debugging) to just fail the allocation instead of just spinning infinitely from an end-use point of view. This will be of great help to dev like me who did not write either software and trying to make them work together :) > For Rumprun, it's quasi-easy to fix. It's actually quite hard to say when a > memory allocation really can never succeed -- the classic CANFAIL memory > allocation problem. It's clear that you can never allocate a wired memory > chunk larger than the amount of physical memory. But how much smaller must > you go before you've stepped out of the "abandon all hope" place? > > Since callers of rump_hypermalloc() aren't stupid (they're kernel code), I'd > say that the right fix is to call hypermalloc with waitok = false and put > some sort of uvm_wait() logic into mmapmem_alloc(). > I am still going through the rumprun source (in bits and pieces) at much slower pace to comment. I do intend to spend more time to get a better handle of things but it will be great to have a quick workaround (and fail) for obvious cases. Is there a cleaner/better way to remove mmap support in rumprun, so applications wont find it and am curious to see how that goes with my case (for the fun of it though). -Neeraj
