From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NmrNV-00016o-1u for qemu-devel@nongnu.org; Wed, 03 Mar 2010 11:24:53 -0500 Received: from [199.232.76.173] (port=54351 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NmrNU-00016S-Kh for qemu-devel@nongnu.org; Wed, 03 Mar 2010 11:24:52 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NmrNT-0002H2-8C for qemu-devel@nongnu.org; Wed, 03 Mar 2010 11:24:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:46230) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NmrNS-0002Gv-OE for qemu-devel@nongnu.org; Wed, 03 Mar 2010 11:24:51 -0500 Date: Wed, 3 Mar 2010 13:24:06 -0300 From: Marcelo Tosatti Subject: Re: [Qemu-devel] Re: [PATCHv2 10/12] tap: add vhost/vhostfd options Message-ID: <20100303162406.GA3550@amt.cnet> References: <20100302161247.GA25371@amt.cnet> <4B8D4350.6040506@codemonkey.ws> <201003022241.27803.paul@codesourcery.com> <4B8E6EF3.5020605@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8E6EF3.5020605@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: quintela@redhat.com, "Michael S. Tsirkin" , qemu-devel@nongnu.org, kraxel@redhat.com, amit.shah@redhat.com, Paul Brook On Wed, Mar 03, 2010 at 08:15:15AM -0600, Anthony Liguori wrote: > On 03/02/2010 04:41 PM, Paul Brook wrote: > >>The new function I'm proposing has the following semantics: > >> > >>- it always returns a persistent mapping > >>- it never bounces > >>- it will only fail if the mapping isn't ram > >So you're assuming that virtio rings are in ram that is not hot-pluggable > > As long as the device is active, yes. This would be true with bare > metal. Memory allocated for the virtio-pci ring is not reclaimable > and you have to be able to reclaim the entire area of ram covered by > a DIMM to hot unplug it. A user would have to unload the virtio-pci > module to release the memory before hot unplug would be an option. > > NB, almost nothing supports memory hot remove because it's very > difficult for an OS to actually do. > > > or > >remapable, > > Yes, it cannot be remapable. > > > and the whole region is contiguous? > > Yes, it has to be contiguous. > > >That sounds like it's likely to come back and bite you. The guest has no idea > >which areas of ram happen to be contiguous on the host. > > Practically speaking, with target-i386 anything that is contiguous > in guest physical memory is contiguous in the host address space > provided it's ram. > > These assumptions are important. I have a local branch (that I'll > send out soon) that implements a ram API and converted virtio to > make use of it. I'm seeing a ~50% increase in tx throughput. > > If you try to support discontiguous, remapable ram for the virtio > ring, then you have to do an l1_phys_map lookup for every single > ring variable access followed by a memory copy. This ends up > costing an awful lot practically speaking. Speed up the lookup instead? > > The changes should work equally well with syborg although I don't > think I can do meaningful performance testing there (I don't > actually have a syborg image to test). > > Regards, > > Anthony Liguori > > >Paul