From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Baysek Subject: Re: vhost-blk development Date: Wed, 11 Apr 2012 12:52:10 -0400 (EDT) Message-ID: <6815254.61554.1334163130932.JavaMail.root@zimbra.liquidweb.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org To: Stefan Hajnoczi Return-path: Received: from mxgate-03.liquidweb.com ([209.59.139.131]:57576 "EHLO mxgate-03.liquidweb.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932418Ab2DKQwN convert rfc822-to-8bit (ORCPT ); Wed, 11 Apr 2012 12:52:13 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: In this particular case, I did intend to deploy these instances directl= y to=20 the ramdisk. I want to squeeze every drop of performance out of these=20 instances for use cases with lots of concurrent accesses. I thought i= t=20 would be possible to achieve improvements an order of magnitude or more= =20 over SSD, but it seems not to be the case (so far). =20 I am purposefully not using O_DIRECT since most workloads will not be u= sing=20 it, although I did notice better performance when I did use it. I did already identify the page cache as a hinderance as well. I seem to have hit some performance ceilings inside of the kvm guests t= hat=20 are much lower than that of the host they are running on. I am seeing = a=20 lot more interrupts and context switches on the parent than I am in the= =20 guests, and I am looking for any and all ways to cut these down. =20 I had read somewhere that vhost-blk may help. However, those patches w= ere=20 posted on qemu-devel in 2010, with some activity on LKML in 2011, but n= ot=20 much since. I feared that the reason they are still not merged might b= e=20 bugs, incomplete implementation, or something of the sort. =20 Anyhow, I thank you for your quick and timely responses. I have spent = some=20 weeks investigating ways to boost performance in this use case and I am= =20 left with few remaining options. I hope I have communicated clearly wh= at I=20 am trying to accomplish, and why I am inquiring specifically about vhos= t-blk. =20 Regards, -Mike ----- Original Message ----- =46rom: "Stefan Hajnoczi" To: "Michael Baysek" Cc: kvm@vger.kernel.org Sent: Wednesday, April 11, 2012 3:19:48 AM Subject: Re: vhost-blk development On Tue, Apr 10, 2012 at 6:25 PM, Michael Baysek = wrote: > Well, I'm trying to determine which I/O method currently has the very= least performance overhead and gives the best performance for both rea= ds and writes. > > I am doing my testing by putting the entire guest onto a ramdisk. =C2= =A0I'm working on an i5-760 with 16GB RAM with VT-d enabled. =C2=A0I am= running the standard Centos 6 kernel with 0.12.1.2 release of qemu-kvm= that comes stock on Centos 6. =C2=A0The guest is configured with 512 M= B RAM, using, 4 cpu cores with it's /dev/vda being the ramdisk on the h= ost. Results collected for ramdisk usually do not reflect the performance you get with a real disk or SSD. I suggest using the host/guest configuration you want to deploy. > I've been using iozone 3.98 with -O -l32 -i0 -i1 -i2 -e -+n -r4K -s25= 0M to measure performance. I haven't looked up the options but I think you need -I to use O_DIRECT and bypass the guest page cache - otherwise you are not benchmarking I/O performance but overall file system/page cache performance. Stefan