From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Avoid fragment virtio-blk transfers by copying Date: Wed, 25 Jun 2008 11:28:46 -0500 Message-ID: <4862723E.5010002@us.ibm.com> References: <1214331384-32217-1-git-send-email-aliguori@us.ibm.com> <48622193.6080401@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from e2.ny.us.ibm.com ([32.97.182.142]:34207 "EHLO e2.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760403AbYFYQ3I (ORCPT ); Wed, 25 Jun 2008 12:29:08 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m5PGT7Fa018210 for ; Wed, 25 Jun 2008 12:29:07 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m5PGT6M1929940 for ; Wed, 25 Jun 2008 12:29:06 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m5PGT5nF027446 for ; Wed, 25 Jun 2008 10:29:06 -0600 In-Reply-To: <48622193.6080401@qumranet.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. An unprivileged user should not be able to OOM the kernel by simply doing memory allocations. Likewise, while it will start swapping, that should primarily effect the application allocating memory (although yes, it's consuming IO bandwidth to do the swapping). As long as we properly handle memory allocation failures, it's my contention that allowing a guest to allocate unbound amounts of virtual memory is safe. > So we need to either fragment beyond some size, or to avoid copying > and thus the need for allocation. As Marcelo mentioned, there are very practical limitations on how much memory can be in-flight on any given queue. A malicious guest could construct a nasty queue that basically pointed to all of the guest physical memory for each entry in the queue but that's still a bound size. Regards, Anthony Liguori