On 08/20/2013 07:06 AM, Michal Privoznik wrote:
> If there's no hard_limit set and domain uses VFIO we still must lock the
> guest memory (prerequisite from qemu). Hence, we should compute the
> amount to be locked from max_baloon.
s/baloon/balloon/
> ---
> src/qemu/qemu_command.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index c8f7df2..71c220f 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -9219,8 +9219,19 @@ qemuBuildCommandLine(virConnectPtr conn,
> goto error;
> }
>
> - if (mlock)
> - virCommandSetMaxMemLock(cmd, def->mem.hard_limit * 1024);
> + if (mlock) {
> + unsigned long long memKB;
> +
> + /* VFIO requires all of the guest's memory to be
> + * locked resident, plus some amount for IO
> + * space. Alex Williamson suggested adding 1GiB for IO
> + * space just to be safe (some finer tuning might be
> + * nice, though).
> + */
> + memKB = def->mem.hard_limit ?
> + def->mem.hard_limit : def->mem.max_balloon + 1024 * 1024;
> + virCommandSetMaxMemLock(cmd, memKB * 1024);
If I'm understanding correctly, this is how much memory can be locked,
but the domain can use more (unlocked) memory as needed. Locked memory
corresponds to what the guest sees, whereas the OOM-killer on hard-limit
was kicking in when qemu itself allocated memory not visible to the
guest. Therefore, this is not presenting the same risk for OOM-killer
as the other hard_limit hueristic was. ACK.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list