From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] Avoid fragment virtio-blk transfers by copying Date: Sun, 29 Jun 2008 12:56:04 +0300 Message-ID: <48675C34.6010400@qumranet.com> References: <1214331384-32217-1-git-send-email-aliguori@us.ibm.com> <48622193.6080401@qumranet.com> <20080625155551.GA3728@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from il.qumranet.com ([212.179.150.194]:37716 "EHLO il.qumranet.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752965AbYF2J4G (ORCPT ); Sun, 29 Jun 2008 05:56:06 -0400 In-Reply-To: <20080625155551.GA3728@dmt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: > On Wed, Jun 25, 2008 at 01:44:35PM +0300, Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> A major source of performance loss for virtio-blk has been the fact that we >>> split transfers into multiple requests. This is particularly harmful if you >>> have striped storage beneath your virtual machine. >>> >>> This patch copies the request data into a single contiguous buffer to ensure >>> that we don't split requests. This improves performance from about 80 MB/sec >>> to about 155 MB/sec with my fibre channel link. 185 MB/sec is what we get on >>> native so this gets us pretty darn close. >>> >>> >>> >> If the guest issues a request for a terabyte of memory, the host will >> try to allocate it and drop to swap/oom. So we need to either fragment >> beyond some size, or to avoid copying and thus the need for allocation. >> > > The maximum request size for Linux guests is 512K (after tuning > virtio-blk guest driver, current max is 124K). I'm not sure what the max > number of requests is, but I guess is between 128 and 1024, Anthony? > > This is assuming 1 page per descriptor. But the len field is 32 bits, so each descriptor can address up to 4GB. > Point is that the guest is responsible for limiting the amount of data > in-flight. A malicious guest can only hurt itself by attempting to DoS > the host, with proper memory limits in place. IMO this issue should not > be handled in the virtio-blk backend I'd like kvm to be safe for use even without the rss controller. -- error compiling committee.c: too many arguments to function