Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in blkfront

["Duan, Ronghui" <ronghui.duan@xxxxxxxxx>]

> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate 
> any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.

I totally agree that we should not break others when enable what we want. 
But just from my mind, the patch only have a little overhead in the 
front/backend code path. It will induce pure random IO with a little overhead.
I tried the 4K read case, I just got 50MB/s w/o the patch. I need a more 
powerful disk to verified it.

Ronghui


> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx]
> Sent: Thursday, September 13, 2012 9:24 PM
> To: Stefano Stabellini
> Cc: Jan Beulich; Duan, Ronghui; Ian Jackson; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [RFC v1 0/5] VBD: enlarge max segment per request in
> blkfront
> 
> On Thu, Sep 13, 2012 at 12:05:35PM +0100, Stefano Stabellini wrote:
> > On Thu, 13 Sep 2012, Jan Beulich wrote:
> > > >>> On 13.09.12 at 04:28, "Duan, Ronghui" <ronghui.duan@xxxxxxxxx> wrote:
> > > >> And with your patch got:
> > > >>   read : io=4096.0MB, bw=92606KB/s, iops=23151 , runt= 45292msec
> > > >>
> > > >> without:
> > > >>   read : io=4096.0MB, bw=145187KB/s, iops=36296 , runt= 28889msec
> > > >>
> > > > What type of backend file you are using? In order to remove the
> > > > influence of cache in Dom0, I use a physical partition as backend.
> > >
> > > But you certainly shouldn't be proposing features getting used
> > > unconditionally or by default that benefit one class of backing
> > > devices and severely penalize others.
> >
> > Right.
> > I am wondering.. Considering that the in-kernel blkback is mainly used
> > with physical partitions, is it possible that your patches cause a
> > regression with unmodified backends that don't support the new
> > protocol, like QEMU for example?
> 
> Well for right now I am just using the most simple configuration to eliminate 
> any
> extra variables (stacking of components). So my "testing" has been just on
> phy:/dev/sda,xvda,w with the sda being a Corsair SSD.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel