Re: [Xen-devel] Handling of out of memory conditions (was: Re: Strange kernel BUG() on PV DomU boot)

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel