From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmkXb-0008SO-Ug for qemu-devel@nongnu.org; Mon, 06 Oct 2008 03:30:04 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmkXa-0008Rs-8d for qemu-devel@nongnu.org; Mon, 06 Oct 2008 03:30:03 -0400 Received: from [199.232.76.173] (port=57336 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmkXa-0008Rp-6D for qemu-devel@nongnu.org; Mon, 06 Oct 2008 03:30:02 -0400 Received: from mx20.gnu.org ([199.232.41.8]:5824) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KmkXZ-0002ro-Pv for qemu-devel@nongnu.org; Mon, 06 Oct 2008 03:30:02 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmkXY-0004yZ-JT for qemu-devel@nongnu.org; Mon, 06 Oct 2008 03:30:00 -0400 Message-ID: <48E9BDF4.8060809@redhat.com> Date: Mon, 06 Oct 2008 09:27:48 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4/4] Reallocate dma buffers in read/write path if needed References: <1223071531-31817-1-git-send-email-ryanh@us.ibm.com> <1223071531-31817-5-git-send-email-ryanh@us.ibm.com> <200810040017.09081.paul@codesourcery.com> <48E6AC36.3060404@codemonkey.ws> <48E73ECD.9080309@redhat.com> <20081004135749.pphehrhuw9w4gwsc@imap.linux.ibm.com> <20081004214700.GH31395@us.ibm.com> <48E7ECC1.90008@codemonkey.ws> <20081005230656.GI31395@us.ibm.com> In-Reply-To: <20081005230656.GI31395@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ryan Harper Cc: qemu-devel@nongnu.org, Anthony Liguori , Paul Brook , kvm@vger.kernel.org Ryan Harper wrote: >> There are two concerns with allowing the guest to alloc arbitrary >> amounts of memory. The first is that QEMU is not written in such a way >> to be robust in the face of out-of-memory conditions so if we run out of >> VA space, an important malloc could fail and we'd fall over. >> > > That is an understandable concern and I don't want to make matters > worse, even if the instability already exists in the code as-is. I think > I'd like to see this fail in practice before I'm really concerned. For > 64-bit builds, is the VA space an issue? > > VA space is virtually (groan) unlimited on x86_64. But note that for every kilobyte of virtual address space you allocate, you consume half a byte in nonpagepable kernel memory. >> The second concern is that if a guest can allocate arbitrary amounts of >> memory, it could generate a swap storm. Unfortunately, AFAIK, Linux is >> not yet to a point where it can deal with swap fairness. Hopefully this >> is a limitation that the IO controller folks are taking into account. >> > > Sure, but as I mentioned, the amount of memory it can allocate can > surely be controlled by the host system per-process ulimit no? > So if the guest issues some large I/Os in parallel, we kill it? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.