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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.06.12 at 14:53, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
>>> wrote:
> On 06/22/12 14:38, Jan Beulich wrote:
>>> > 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?

In the case at hand, failing CPU bringup rather than invoking
BUG() would likely be possible. Then the guest would come up
single-CPU. (That's a more general theme though: Many BUG()
instances really don't need to be as harsh.)

SWIOTLB allocation is a different thing - if the guest really needs
it, yet fails to set it up, the most it could do is to defer the crash
until the first I/O needs to make use of it. Which likely doesn't buy
much to the user.

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

If you're running your own hypervisor, you could go and backport
all those changes. If you running some vendor's, you could ask
them to (but if you asked us, we'd likely would [try to] refuse).

Jan


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