qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] automatic exit on memory errors


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] automatic exit on memory errors
Date: Wed, 11 Apr 2012 12:38:44 +0100

On Wed, Apr 4, 2012 at 5:38 PM, Frediano Ziglio <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]