On Wed, Apr 4, 2012 at 5:38 PM, Frediano Ziglio <fredd...@gmail.com> wrote: > Anybody considered this problem?
In QEMU there are a few different types of memory allocation: 1. Internal data structures allocated at startup. This happens before the VM is running exiting on out-of-memory is fine here. 2. Transient allocations for guest device emulation or host device handling - mostly I/O buffers or request structures. These should be bounded because an emulated device only has a finite ring size or maximum number of simultaneous requests. If these allocations are unbounded then we risk out-of-memory errors and we should not allow this. Even for bounded allocations we could run out of memory on the host and we abort the QEMU process here today. 3. Dynamic internal data structures that are allocated at runtime. Hotplug and other runtime operations. Usually exiting is not the desired behavior here. But given the layers JSON/QMP/etc we have for communicating with QEMU I wonder whether any sort of error message could be communicated back to the caller successfully. For #2 we don't always use g_malloc() - we also use qemu_blockalign() (which uses posix_memalign(3)) or pools. For qemu_blockalign() we could actually handle out-of-memory and fail the request. For pools we can either fail the request or wait until an entry in the pool becomes free. Ideally QEMU would be very disciplined about memory allocations. In practice we'll hit swap first and users will notice poor performance, I can't recall an out-of-memory issue ever being reported. Introducing a more systematic approach for #2 allocations would be nice but I don't think it will buy us much in practice over what we have now. Stefan
