From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [RFC v1 0/5] VBD: enlarge max segment per request in blkfront Date: Thu, 13 Sep 2012 09:23:37 -0400 Message-ID: <20120913132335.GD16635@localhost.localdomain> References: <20120907174922.GA13040@phenom.dumpdata.com> <5051A83B020000780009AF93@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Ronghui Duan , Ian Jackson , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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" 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.