From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kmch9-0002kj-56 for qemu-devel@nongnu.org; Sun, 05 Oct 2008 19:07:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kmch8-0002k9-LN for qemu-devel@nongnu.org; Sun, 05 Oct 2008 19:07:22 -0400 Received: from [199.232.76.173] (port=48363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kmch8-0002k3-Dx for qemu-devel@nongnu.org; Sun, 05 Oct 2008 19:07:22 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:51946) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kmch7-0006La-TA for qemu-devel@nongnu.org; Sun, 05 Oct 2008 19:07:22 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id m95N4bgX030947 for ; Sun, 5 Oct 2008 19:04:37 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m95N7Iqk208656 for ; Sun, 5 Oct 2008 19:07:18 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m95N77ku008401 for ; Sun, 5 Oct 2008 19:07:08 -0400 Date: Sun, 5 Oct 2008 18:06:56 -0500 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 4/4] Reallocate dma buffers in read/write path if needed Message-ID: <20081005230656.GI31395@us.ibm.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48E7ECC1.90008@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , kvm@vger.kernel.org, qemu-devel@nongnu.org, Ryan Harper , Paul Brook , Avi Kivity * Anthony Liguori [2008-10-04 17:28]: > Ryan Harper wrote: > >I'd rather avoid any additional accounting overhead of a pool. If 4MB > >is a reasonable limit, lets make that the new max. I can do some > >testing to see where we drop off on performance improvements. We'd > >have a default buffer size (smaller than the previous 64, and now 128k > >buf size) that is used when we allocate scsi requests; scanning through > >send_command() provides a good idea of other scsi command buf usage; and > >on reads and writes, keep the capping logic we've had all along, but > >bump the max size up to something like 4MB -- or whatever tests results > >show as being ideal. > > > >In all, it seems silly to worry about this sort of thing since the > >entire process could be contained with process ulimits if this is really > >a concern. Are we any more concerned that by splitting the requests > >into many smaller requests that we're wasting cpu, pegging the > >processor to 100% in some cases? > > > > 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? > > 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? -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com