This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: [kvm-devel] [PATCH RFC 3/3] virtio infrastructure: examp

To: Troy Benjegerdes <hozer@xxxxxxxxx>
Subject: [Xen-devel] Re: [kvm-devel] [PATCH RFC 3/3] virtio infrastructure: example block driver
From: Carsten Otte <cotte@xxxxxxxxxx>
Date: Thu, 31 May 2007 19:01:38 +0200
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "jmk@xxxxxxxxxxxxxxxxxxx" <jmk@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, carsteno@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, mschwid2@xxxxxxxxxxxxxxxxxx, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>
Delivery-date: Thu, 31 May 2007 10:29:34 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070531150206.GB6474@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Deutschland Entwicklung GmbH,Vorsitzender des Aufsichtsrats: Johann Weihen,Geschäftsführung: Herbert Kircher,Sitz der Gesellschaft: Böblingen,Registergericht: Amtsgericht Stuttgart, HRB 243294
References: <1180613947.11133.58.camel@xxxxxxxxxxxxxxxxxxxxx> <1180614044.11133.61.camel@xxxxxxxxxxxxxxxxxxxxx> <1180614091.11133.63.camel@xxxxxxxxxxxxxxxxxxxxx> <465EC637.7020504@xxxxxxxxxx> <20070531150206.GB6474@xxxxxxxxxxxxxx>
Reply-to: carsteno@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla-Thunderbird (X11/20070521)
Troy Benjegerdes wrote:
This kind of a claim needs some benchmark data to document it.
We've implemented both for our vdisk driver on 390. At least on our platform, merging in the host is preferable because vmenter/vmexit is very fast and we would merge twice because we submit the result via io_submit() system call from host userland. In the end you'd need to measure on all platforms this is gonna run on, if you want competitive benchmarks. That makes the benchmark argument somewhat fuzzy.

I'll make the counterclaim that you *should* be doing I/O scheduling in
the guest, both to be able to test new I/O schedulers, and to provide
a set of pre-scheduled I/Os so the host has to do less work.
What makes the work to merge requests less, if done in the host? Is'nt it the same code really if you run Linux in both host and guest?

If someone really needs the host to be doing I/O scheduling, and not the
guest, then why are they using virtualization in the first place?
Just to run multiple operating systems on one box. Funny question...

so long,

Xen-devel mailing list