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] PHY vs. VD benchmark

To: "Tvrtko A. Uršulin" <tvrtko@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] PHY vs. VD benchmark
From: Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>
Date: Tue, 17 Feb 2004 15:49:02 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 Feb 2004 16:07:10 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Message from "Tvrtko A. Uršulin" <tvrtko@xxxxxxxxxxxx> of "Tue, 17 Feb 2004 16:01:38 +0100." <200402171601.38758.tvrtko@xxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
Cool!  Thanks for the info - there haven't been any benchmarks on virtual 
disks yet, so it's good to have some figures.

A couple of comments:

VD space has probably been allocated at the end of the drive, not the start.  
The VD management layer tries to allocate new space from the end (not the 
start) of the longest expired disk, first.

The idea behind this was to preserve any meta data at the start of the expired 
disk being scavenged from, in case of a future option for "partial undeletion" 
of expired disks whose space has been reallocated.  In practice, I suspect 
most filesystems people will use are a little cleverer in terms of where they 
place their metadata, so this may not actually help much.

I suspect you might be able to increase the performance by using a different 
extent size.  The VD management code allocates extents of "initialised" 
physical disks.  The extent size for a device can be specified when it's 
initialised.  The default is 64 megabytes.  A 4 gigabyte virtual disk would 
make for 64 extents of 64 meg.  A long list of extents could be slowing down 
the disk address translation in Xen, resulting in poorer benchmark results.  
At some stage I might rethink the default extent size.

If you want, you could try a larger extent size by specifying it at 
initialisation time.  [ you can't change the extent size on an already 
initialised device :-( ].  This might speed things up in the benchmark, 
although if you don't allocate space in multiples of the extent size there 
will be more space in unused "partial extents" than for a smaller extent size.

In the degenerate case that your entire virtual disk fits inside an extent, it 
should give exactly the same performance as for the phy case (since the code 
will be doing exactly the same thing).

If I get some spare time I might test this out myself - right now I'm 
debugging a different problem.

Cheers,

Mark



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel