WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support. (RFC

To: "Anthony Liguori" <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support. (RFC)
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Mon, 19 Jun 2006 12:22:06 -0700
Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>, Julian Chesterfield <julian.chesterfield@xxxxxxxxxxxx>
Delivery-date: Mon, 19 Jun 2006 12:22:31 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ez+IDu38sYLcASWoKtiG0bIZ48mhjWr63jwo+RfM6W2pRakCNLPxr8LIQGyyi9yNcmC0kP6edpom3mL7ZjqIJUQTjNS5+YuJ7Vbjbb/jLg2wc5KlywBdgnR3IZjZunwMtolUB5RI19AAlqMVt50ILd4B42Ws7Rm3KiSCTJbtXSs=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4496F30E.6020006@xxxxxxxxxx>
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>
References: <eacc82a40606190919x4bd4ef22m9d8431e650e85a67@xxxxxxxxxxxxxx> <4496F30E.6020006@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Anthony,


What is img-sp?  Is this blktap + a physical device or is this blktap
with something like qcow?

Oops, good question.  This is blktap backed off of a sparse image file
(generated with something along the lines of "dd if=/dev/zero
of=./scratch.img bs=1024 seek=<big number>").  So this test is
directly comparable to blkback with a loopback-mounted image, which is
what's shown on the next line.

The numbers a tad worse than I'd expect them to be if it was a physical
device.  Theoretically, linux-aio is inserting requests directly into
the backend.  I expect there to be a certain amount of CPU overhead from
context switching but since it's still zero-copy, I wouldn't expect less
CPU usage and less throughput.

Any idea why this is or am I just totally misunderstanding how things
should behave :-)

Performance on raw devices is certainly better than on images -- I
didn't have a spare partition to work with on my test box this morning
(maybe I can use that as an excuse to get an extra disk), but will get
some results posted on this asap.

A very much like the idea of a userspace block device backend.  Have you
considered what it would take to completely replace blkback with a
userspace backend?  I'm also curious why you choose a character device
to interact with the ring queue instead of just attaching to the ring
queue directly in userspace.

The current blktap code has functional parity with blkback.  Just
change 'phys:' to 'tap:aio:' in your vm config files and you're set.

I think the whole discussion of COW support is orthogonal to a userspace
backend FWIW so I'll save that part of the discussion for another thread :-)

Fair enough, I'll look forward to it. ;)

a.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>