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: Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] PHY vs. VD benchmark
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 17 Feb 2004 16:36:09 +0000
Cc: "Tvrtko A. Uršulin" <tvrtko@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Tue, 17 Feb 2004 16:51:38 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 17 Feb 2004 15:49:02 GMT." <E1At7T5-0005yD-00@xxxxxxxxxxxxxxxxxxxx>
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
> 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.


Any difference in performance must surely be down to the physical
position of the data on the disk (and hence transfer rate): 64MB
extents are sufficiently big not to introduce many extra seeks in
a transfer, even if they weren't contiguous, which they likely
are. The fact that we have to search a linked list of 64 extents
for every transfer is pretty naive, but hardly likely to take
long enough to actually produce a noticeable slowdown.

I think the likely problem is that vdtool is populating the disk
from the last sector, so you're getting the slow bit of the disk
first. The fact that each of the extents are effectively in the
wrong order probably isn't giving Xen's disk scheduler optimal
performance either.

Mark: could you initialise the free list on a newly created VD
partition 'backwards' so we allocate from the front and
sequentially allocated extents are forward on disk?

Thanks,
Ian


-------------------------------------------------------
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