From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 4/4] Reallocate dma buffers in read/write path if needed Date: Sun, 5 Oct 2008 18:06:56 -0500 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 Cc: Ryan Harper , Paul Brook , Anthony Liguori , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org To: Anthony Liguori Return-path: Received: from e3.ny.us.ibm.com ([32.97.182.143]:48728 "EHLO e3.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755397AbYJEXHj (ORCPT ); Sun, 5 Oct 2008 19:07:39 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m95N7Sar024251 for ; Sun, 5 Oct 2008 19:07:28 -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 m95N7IF3231394 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 m95N77l2008401 for ; Sun, 5 Oct 2008 19:07:08 -0400 Content-Disposition: inline In-Reply-To: <48E7ECC1.90008@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: * 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