Re: Handling of out of memory conditions

[Joanna Rutkowska <joanna@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]

On 06/22/12 15:02, Jan Beulich wrote:
>>>> On 22.06.12 at 14:53, Joanna Rutkowska <joanna@invisiblethingslab.com> 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.
> 

How about having the guest kernel (e.g. every time it is about to BUG())
write the cause of the Xen-related runtime errors (such as out of memory
conditions) to some predefined xenstore key, which would allow the
management tools/whatever other software to retrieve that easily and
display a meaningful message to the user? Hm... access to the xenstore
might not be easy at the early VM boot stage -- so perhaps writing it
into some predefined shared page, that could be easily read by the
toolstack?

joanna.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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