From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:56354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxHmP-0002F5-4t for qemu-devel@nongnu.org; Tue, 14 Feb 2012 07:46:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RxHmK-00007T-JC for qemu-devel@nongnu.org; Tue, 14 Feb 2012 07:46:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:15593) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RxHmK-00007O-9C for qemu-devel@nongnu.org; Tue, 14 Feb 2012 07:46:40 -0500 Date: Tue, 14 Feb 2012 12:46:31 +0000 From: "Daniel P. Berrange" Message-ID: <20120214124631.GC29982@redhat.com> References: <1328884453-1067-1-git-send-email-zwu.kernel@gmail.com> <4F353D75.2050801@weilnetz.de> <201202141242.58685.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201202141242.58685.paul@codesourcery.com> Subject: Re: [Qemu-devel] [PATCH] oslib: make error handling more reasonable Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Zhi Yong Wu , Stefan Weil , qemu-devel@nongnu.org, Markus Armbruster On Tue, Feb 14, 2012 at 12:42:58PM +0000, Paul Brook wrote: > > > abort can create core dumps or start a debugger which is > > > useful for me and maybe other developers, too. > > > > I consider abort() on OOM somewhat eccentric. abort() is for > > programming errors. Resource shortage is an environmental error that is > > sometimes (but not always) caused by a programming error. > > > > I'd rather inconvenience programmers (by making it a little bit harder > > to debug programming errors that cause OOM) than confuse users with > > inappropriate scary "crashes". > > While I agree that abort() is not the most friendly failure method, I don't > tthink it's worth trying to handle OOM gracefully. Once we hit OOM I'd say > we're pretty much beyond hope. The best thing we can do is exist as quickly > as possible. For the vast majority of systems there isn't any reason to > believe things will somehow get better if we try again later. > > Initial guest RAM allocation is maybe a special case worth a polite error. > OTOH if you're near the limit then there's a fair chance the -m allocation > will succeed, but some later allocation will not. > > The only way to handle this rebustly is to pre-allocate all the memory we're > ever going to need[1]. I don't see that happening. FWIW, users can already opt-in to pre-allocation if running KVM enabled QEMU -mem-path /dev/shm -mem-prealloc (or /dev/hugepages more usefully) Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|