From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6dok-0005PH-Fy for qemu-devel@nongnu.org; Wed, 09 Dec 2015 07:25:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a6doh-0005yQ-9r for qemu-devel@nongnu.org; Wed, 09 Dec 2015 07:25:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a6doh-0005yF-4F for qemu-devel@nongnu.org; Wed, 09 Dec 2015 07:25:55 -0500 References: <87a8pl9hmt.fsf@blackfin.pond.sub.org> <20151208141938.GB2593@work-vm> <87io480y0n.fsf@blackfin.pond.sub.org> <20151209102931.GC2712@work-vm> From: Laszlo Ersek Message-ID: <56681DCF.6040109@redhat.com> Date: Wed, 9 Dec 2015 13:25:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Error handling in realize() methods List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , "Dr. David Alan Gilbert" Cc: QEMU Developers , Paolo Bonzini , Peter Crosthwaite , Markus Armbruster , =?UTF-8?Q?Andreas_F=c3=a4rber?= On 12/09/15 12:47, Peter Maydell wrote: > On 9 December 2015 at 10:29, Dr. David Alan Gilbert 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 >