From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45890) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvtWd-0002ZD-0t for qemu-devel@nongnu.org; Fri, 10 Feb 2012 11:40:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvtWX-00061V-4f for qemu-devel@nongnu.org; Fri, 10 Feb 2012 11:40:42 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42230 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvtWW-00061P-QB for qemu-devel@nongnu.org; Fri, 10 Feb 2012 11:40:37 -0500 Message-ID: <4F354883.602@suse.de> Date: Fri, 10 Feb 2012 17:40:35 +0100 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Memory: how to determine the max memory size of one VM? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Zhi Yong Wu , Stefan Weil , QEMU Developers , Alexander Graf Am 10.02.2012 11:36, schrieb Stefan Hajnoczi: > On Fri, Feb 10, 2012 at 10:35 AM, Stefan Hajnoczi = wrote: >> On Fri, Feb 10, 2012 at 9:47 AM, Zhi Yong Wu wr= ote: >>> Today i tried to create one VM with the option "-m 4000", and found i= t >>> failed with the following errors: >>> >>> Failed to allocate 4194304000 B: Cannot allocate memory >>> Aborted (core dumped) >> >> Did you run on a 32-bit host? >=20 > BTW we shouldn't abort(3). There's two slightly different scenarios to consider here: i) User specifies command line options that cannot possibly work. =3D> Ideally, yeah, we should just provide an understandable error messag= e and exit with error code. ii) Some tracing of mine indicates QEMU has a highly dynamic memory usage during runtime, be it due to network layer, block layer or whatever exactly. Any memory allocation of those may fail due to soft or hard limits, including pthread_create. =3D> We should not abort because the previously running guest is gone and it's data may be incomplete or corrupted. Not to mention that libvirt shows an odd error message. Problem is that there is no distinction at this point, so if we remove the abort(3) for use case i) we loose it for debugging ii) as well. What would be cool is finding some way to avoid dynamic allocations after guest startup (i.e., preallocated memory pools) and dealing with running out of space there in a non-fatal way. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg