From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joanna Rutkowska Subject: Handling of out of memory conditions (was: Re: Strange kernel BUG() on PV DomU boot) Date: Fri, 22 Jun 2012 14:53:18 +0200 Message-ID: <4FE46ABE.9010104@invisiblethingslab.com> References: <4FE46366.8010104@invisiblethingslab.com> <4FE46486.8020502@invisiblethingslab.com> <4FE4835D020000780008B6B3@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4725527832337227313==" Return-path: In-Reply-To: <4FE4835D020000780008B6B3@nat28.tlf.novell.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: Jan Beulich Cc: Marek Marczykowski , xen-devel List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============4725527832337227313== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig651C6EC0550E9863C2A15CEA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig651C6EC0550E9863C2A15CEA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: >> >=20 >> > xl mem-set 0 1800m >> >=20 >> > 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. >=20 Ah, right, good point. >> > Is there any proposal of how to handle out of memory conditions in X= en >> > (like this one, as well as e.g. SWIOTLB problem) in a more user frie= ndly >> > 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. >=20 > 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. >=20 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. --------------enig651C6EC0550E9863C2A15CEA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJP5Gq+AAoJEDaIqHeRBUM0bg0IAMdd2l0fBZSY0FSQtISCdqnu nMw9w57F5PJ8lf591NPNGbWhsim+mE0mk9njz0O58m+5Eywg6JKWUel3jlrQwcsB c7QC3q+cManbztPGXPp2rRs/sPIMEM+tW7RyGwyzEPjLmspoMSFUU+RZhScyY6+Y 3nhN4Mno7BdJ26hC+oO9Ok9WDt1dj09Gbvxug2XDIurzYfPXvUBD+V8NeWEiXwpf qcJXOKSidhxOxTBQzG+8dFYD8dFYsvNKRvIGfNBogYYzq1WvUNGeQ9Q4hTb6lSZT AbQHRWJMvQ3+jJnePHdcYwI9AWEsf3wqWyI0IrG7LPLFKY4amszro7ViTzrzmto= =pM5I -----END PGP SIGNATURE----- --------------enig651C6EC0550E9863C2A15CEA-- --===============4725527832337227313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============4725527832337227313==--