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

[Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx>]

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?

>> > Any recommendations regarding the preferred minimum Xen free memory, as
>> > reported by xl info, that should be preserved in order to assure Xen
>> > runs smoothly?
> In pre-4.2 Xen, there's not much you can do when memory gets
> fragmented (otherwise you'd have to keep more than half the
> memory in the box in the hypervisor). With multi-page runtime
> allocations gone, you should be fine leaving just a minimal amount
> to the hypervisor.

Right, but 4.2 will not be released until weeks or months :/ And we
would like to release Qubes 1.0 within weeks...

joanna.

Attachment: signature.asc
Description: OpenPGP digital signature

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