[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] blk[front|back] does not hand over disk parameters



On Fri, 2011-02-25 at 16:43 +0000, Adi Kriegisch wrote:
> Dear all,
> 
> (following the XenFAQ on how to report a bug[1], I submitted this to
> xen-user list[2] first, reported the bug in bugzilla[3] and now resend the
> text to this list. Please CC me in replys as I am not subscribed to this
> list, Thanks!)
> 
> I investigated some serious performance drop between Dom0 and DomU with
> LVM on top of RAID6 and blkback devices.
> While I have around 130MB/s write performance in Dom0, I only get 30MB/s in
> DomU. Inspecting this with dstat/iostat revealed that I have a read rate of
> about 17-25MB/s while writing with aroung 40MB/s.
> The reading only occurs on the disk devices assembled to the RAID6 not the
> md device itself. So this is related to RAID6 activity only.
> The reason for this is recalculation of checksums due to a too small
> optimal_io_size:
> On Dom0:
> blockdev --getiomin /dev/space/test
> 524288 (which is chunk size)
> blockdev --getioopt /dev/space/test
> 3145728 (which is 6*chunk size)
> 
> On DomU:
> blockdev --getiomin /dev/xvdb1
> 512
> blockdev --getioopt /dev/xvdb1
> 0 (so the kernel will use 1MB by default, IIRC)
> 
> minimum_io_size -- if not set -- is hardware block size which seems to be
> set to 512 in xlvbd_init_blk_queue (blkfront.c). Btw: blockdev --getbsz
> /dev/space/test gives 4096 on Dom0 while DomU reports 512.
> 
> I can somehow mitigate the issue by using a way smaller chunk size but this
> is IMHO just working around the issue. Another workaround could be to use a
> "power-of-two" number of data disks in the raid and choose the chunk size
> to sum up to 1MB. But this is just another hack...
> 
> If there is anything I can do, please let me know!

This is not the sort of thing which changes dynamically across the
lifetime of a device, is it? In which case it seems like the sort of
information which the backend could communicate to the frontend via
xenbus at start of day. e.g. take a look at how the sector-size is
passed through xenbus. 

It should be trivial to add this in a compatible manner since the
frontend can just do what it does today if the nodes are missing and the
backend wouldn't rely on the frontend doing anything useful with the
information anyway.

Can you make a patch?

Ian.

> 
> Thanks,
>         Adi Kriegisch
> 
> PS: I am using a stock Debian/Squeeze kernel on top of Debians Xen 4.0.1-2.
> 
> [1] http://wiki.xensource.com/xenwiki/XenFaq
> [2] http://lists.xensource.com/archives/html/xen-users/2011-02/msg00615.html
> [3] http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1745
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.