From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Handling of out of memory conditions (was: Re: Strange kernel BUG() on PV DomU boot) Date: Mon, 25 Jun 2012 11:39:49 -0400 Message-ID: <20120625153949.GD4210@phenom.dumpdata.com> References: <4FE46366.8010104@invisiblethingslab.com> <4FE46486.8020502@invisiblethingslab.com> <4FE4835D020000780008B6B3@nat28.tlf.novell.com> <4FE46ABE.9010104@invisiblethingslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4FE46ABE.9010104@invisiblethingslab.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Joanna Rutkowska Cc: Marek Marczykowski , Jan Beulich , xen-devel List-Id: xen-devel@lists.xenproject.org On Fri, Jun 22, 2012 at 02:53:18PM +0200, Joanna Rutkowska wrote: > On 06/22/12 14:38, Jan Beulich wrote: > >> Ok, it seems like this was an out-of-memeory condition indeed, because > >> > once I did: > >> > > >> > xl mem-set 0 1800m > >> > > >> > and then quickly started a VM, it booted fine... > > Had you looked at the error value in %rax, you would also > > have seen that it's -ENOMEM. I suppose the problem here is > > that a multi-page allocation was needed, yet only single > > pages were available. > > > > Ah, right, good point. > > >> > Is there any proposal of how to handle out of memory conditions in Xen > >> > (like this one, as well as e.g. SWIOTLB problem) in a more user friendly > >> > way? > > In 4.2, I hope we managed to remove all runtime allocations > > larger than a page, so the particular situation here should arise > > anymore. > > > > As to more user-friendly - what do you think of? An error is an > > error (and converting this to a meaningful, user visible message > > is the responsibility of the entity receiving the error). In the > > case at hand, printing an error message wouldn't meaningfully > > increase user-friendliness imo. > > > > How would you suggest to let the user (in an interactive desktop system, > such as Qubes) know why his or her VM doesn't start? Certainly, some > savvy user might just analyze the guest's dmesg log but that's really > not a user friendly solution. And yet the out of memory errors are > something that might happen quite often and are not really "exception" > or "errors" in the same sense as e.g. traditional BUG() conditions that > suggest something really bad happened. The problem here is that this bug > occurs after the domain has been built, and is now running, so xl start > is not a good place to return the error. Same with SWIOTLB out of memory > errors, that again just prevent the domain from starting. Any other > ideas how to handle such situations more gracefully? Right now SWIOTLB retries with smaller sizes..