From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmMCm-0006Su-W0 for qemu-devel@nongnu.org; Sun, 05 Oct 2008 01:30:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmMCm-0006Si-6q for qemu-devel@nongnu.org; Sun, 05 Oct 2008 01:30:56 -0400 Received: from [199.232.76.173] (port=56242 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmMCm-0006Sf-1V for qemu-devel@nongnu.org; Sun, 05 Oct 2008 01:30:56 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52556) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmMCm-0007Iy-41 for qemu-devel@nongnu.org; Sun, 05 Oct 2008 01:30:56 -0400 Message-ID: <48E84F3D.4070301@redhat.com> Date: Sun, 05 Oct 2008 07:23:09 +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> In-Reply-To: <48E7ECC1.90008@codemonkey.ws> 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: Anthony Liguori Cc: Anthony Liguori , Ryan Harper , qemu-devel@nongnu.org, kvm@vger.kernel.org, Paul Brook Anthony Liguori wrote: > > 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. Even if Linux was 100% fair (or rather 100% controlled -- we don't want fairness here) in dealing with memory overcommit, we don't want swapping just because a guest issued large requests. Breaking up large requests will reduce efficiency (I believe negligibly is the limit is 1MB or above), swapping will be much worse. And again, there's no real reason to allocate memory here, we should be doing I/O directly to the guest's scatter/gather buffers. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.