qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Error handling in realize() methods


From: Laszlo Ersek
Subject: Re: [Qemu-devel] Error handling in realize() methods
Date: Wed, 9 Dec 2015 13:25:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

On 12/09/15 12:47, Peter Maydell wrote:
> On 9 December 2015 at 10:29, Dr. David Alan Gilbert <address@hidden> wrote:
>> (OK, to be honest I think we should protect every allocation - but I do
>> have sympathy with the complexity/testing arguments).
> 
> My view on this is that Linux overcommits, so the actual likely
> way that "oops, out of memory" will manifest is by some page not
> being able to be allocated-on-demand, at which point your process
> is toast anyway.

This is a frequent argument, but this behavior is not acceptable for
many production workloads (for example, it is not acceptable on my
laptop :)), and it can be disabled with the overcommit knobs under
/proc/sys/vm.

Also, the OOM killer destroying the "wrong" process is a recurrent
source of fun.

Of course, under memory pressure there is no telling which process will
get ENOMEM first, even with overcommit disabled, but that setting at
least allows the process to deal with the error, should it choose so.

On a heavy duty virtualization host, one can expect that *only* such
applications run that can "behave" in response to ENOMEM -- I believe
libvirtd is an example? --; hence disabling overcommit is especially valid.

(I continue to offer my (unsolicited) opinion in this thread, and I
continue encouraging QEMU people to ignore it whenever appropriate. I
don't strive to influence the decision; I'd just like to contribute to
the well-informed nature of the decision.)

Thanks
Laszlo

> Checking malloc returns is really only checking
> your virtual address space allocation, which typically speaking
> always succeeds, except in the "we tried to get gigabytes at
> once" case...
> 
> thanks
> -- PMM
> 




reply via email to

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