From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH 4/4] Reallocate dma buffers in read/write path if needed Date: Sat, 4 Oct 2008 01:00:27 +0100 Message-ID: <200810040100.28341.paul@codesourcery.com> References: <1223071531-31817-1-git-send-email-ryanh@us.ibm.com> <200810040017.09081.paul@codesourcery.com> <48E6AC36.3060404@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Anthony Liguori , Anthony Liguori , Ryan Harper , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail.codesourcery.com ([65.74.133.4]:44803 "EHLO mail.codesourcery.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753210AbYJDAAa convert rfc822-to-8bit (ORCPT ); Fri, 3 Oct 2008 20:00:30 -0400 In-Reply-To: <48E6AC36.3060404@codemonkey.ws> Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: On Saturday 04 October 2008, Anthony Liguori wrote: > Paul Brook wrote: > > On Friday 03 October 2008, Ryan Harper wrote: > >> The default buffer size breaks up larger read/write requests > >> unnecessarily. When we encounter requests larger than the default = dma > >> buffer, reallocate the buffer to support the request. > > > > Allocating unboundedly large host buffers based on guest input seem= s like > > a bad idea. > > Perhaps they could be at least bound to phys_ram_size. That's still way too large. It means that the maximum host footprint o= f qemu=20 is many times the size of the guest RAM. There's a good chance that the= host=20 machine doesn't even have enough virtual address space to satisfy this=20 request. I expect that the only situation where you can only avoid breaking up l= arge=20 transfers when you have zero-copy IO. Previous zero-copy/vectored IO p= atches=20 suffered from a similar problem: It is not acceptable to allocate huge = chunks=20 of host ram when you fallback to normal IO. > In general, I don't think there's a correct size to bound them that's > less than phys_ram_size. =A0The guest may be issuing really big IO re= quests. Qemu is perfectly capable of handling large IO requests by splitting th= em into=20 multiple smaller requests. Enlarging the size of this buffer is just a=20 secondary performance optimisation. Admittedly we don't currently limit the number of simultaneous commands= a=20 guest can submit, but that's relatively easy to fix. Paul