qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Zhi Yong Wu <zwu.kernel@gmail.com>, Stefan Weil <sw@weilnetz.de>,
	Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] oslib: make error handling more reasonable
Date: Tue, 14 Feb 2012 12:42:58 +0000	[thread overview]
Message-ID: <201202141242.58685.paul@codesourcery.com> (raw)
In-Reply-To: <m3zkcmlthf.fsf@blackfin.pond.sub.org>

> > 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.

Paul

[1] And make sure the kernel isn't lying about how much ram we can have.

  parent reply	other threads:[~2012-02-14 12:43 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-10 14:34 [Qemu-devel] [PATCH] oslib: make error handling more reasonable Zhi Yong Wu
2012-02-10 14:41 ` Daniel P. Berrange
2012-02-10 15:13   ` Zhi Yong Wu
2012-02-10 15:53     ` Stefan Weil
2012-02-13  2:37       ` Zhi Yong Wu
2012-02-13  6:29         ` Stefan Weil
2012-02-13 11:16           ` Stefan Hajnoczi
2012-02-14 12:46             ` Anthony Liguori
2012-02-14 12:45           ` Anthony Liguori
2012-02-13 14:04       ` Markus Armbruster
2012-02-13 14:30         ` Peter Maydell
2012-02-14 12:42         ` Paul Brook [this message]
2012-02-14 12:46           ` Daniel P. Berrange
2012-02-14 13:07             ` Paul Brook
2012-02-14 12:47         ` Anthony Liguori
2012-02-10 18:35   ` Eric Blake
2012-02-13  2:42     ` Zhi Yong Wu
2012-02-13  9:17     ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201202141242.58685.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    --cc=zwu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).