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] Add multi-page shared ring support toxen-blkfront/back

To: "Daniel Stodden" <daniel.stodden@xxxxxxxxxx>
Subject: RE: [Xen-devel] Add multi-page shared ring support toxen-blkfront/back
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Wed, 13 Jan 2010 17:03:13 +1100
Cc: Paul Durrant <Paul.Durrant@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 12 Jan 2010 22:03:38 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1263331365.18136.214.camel@xxxxxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1263318297-18527-1-git-send-email-paul.durrant@xxxxxxxxxx> <4B4CB6AE.70005@xxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D018989BA@trantor> <1263331365.18136.214.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqTzXvxGYMDwVxyRDqd0ecVAp1opwARMysA
Thread-topic: [Xen-devel] Add multi-page shared ring support toxen-blkfront/back
> 
> On Tue, 2010-01-12 at 15:58 -0500, James Harper wrote:
> 
> > I received the 1/2 and 2/2 emails containing the patches.
> >
> > Is there any measurable performance increase with this update? I assume
> > it means that you can have more read/write operations on the ring at
> > once? What would be useful to me is larger read/write operations...
> 
> Interesting. Why? Asking because ring space is spent on segments, not
> request headers. Do you see a notable difference somewhere, compared to
> a bunch of (virtually) consecutive request ranges? Or rather a
> convenience thing for the gpl PV drivers?
> 

Windows has a limit to the number of outstanding requests that it will issue. 
It is as low as 16 under some versions of their scsiport infrastructure. I 
think storport relaxes those limits a bit but I haven't gotten as far as a 
storport driver yet.

So larger requests would probably benefit windows more than more requests would.

It would be nice if the ring slots could be dynamic in size. Major rewrite of 
everything of course, but we'd get the best of both worlds.

James

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