From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LUydk-0008I0-Ek for qemu-devel@nongnu.org; Thu, 05 Feb 2009 02:27:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LUydj-0008Ho-Mj for qemu-devel@nongnu.org; Thu, 05 Feb 2009 02:27:12 -0500 Received: from [199.232.76.173] (port=46424 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LUydj-0008Hl-Im for qemu-devel@nongnu.org; Thu, 05 Feb 2009 02:27:11 -0500 Received: from mx2.redhat.com ([66.187.237.31]:58022) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LUydj-0000OP-5q for qemu-devel@nongnu.org; Thu, 05 Feb 2009 02:27:11 -0500 Message-ID: <498A9463.3000002@redhat.com> Date: Thu, 05 Feb 2009 09:25:23 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 1/4] Add a scatter-gather list type and accessors References: <1233750314-23301-1-git-send-email-avi@redhat.com> <4989FC3B.7010407@us.ibm.com> <4989FE92.5020400@redhat.com> <200902042358.13955.paul@codesourcery.com> In-Reply-To: <200902042358.13955.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Anthony Liguori , qemu-devel@nongnu.org Paul Brook wrote: > I disagree about "Linux is fairly useless without overcommit". Certain common > linux applications maybe, however... > qemu is one. The use of fork() to run scripts means qemu's memory commit can double, even though in practice this memory will not be used. I've tried running with strict overcommit control once, the desktop crashed left and right even after adding ridiculous amounts of swap. >> Other ways of allocating memory (stack growth, first access to anonymous >> memory) are not covered. They can fail (most ungracefully) without >> strict overcommit control. >> >> So I suggest to have qemu_malloc() and its friends abort on failure. >> > > I'll support this. In theory it's sometimes possible to recover from Out Of > Memory conditions. However in practice I don't think there's any real scope > for this in qemu. If were allocating huge chunks of ram on the fly then > something else is already badly wrong. > > IMHO pushing the error up (down?) the callchain is unlikely to provide the > user with significantly better information, we may as well bail out in > qemu_malloc. > I'll post a patch. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.