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/
Home Products Support Community News


RE: [Xen-devel] [Patch] Buffer disk I/O requests

To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [Patch] Buffer disk I/O requests
From: "Han, Weidong" <weidong.han@xxxxxxxxx>
Date: Sun, 20 May 2007 21:57:32 +0800
Delivery-date: Sun, 20 May 2007 06:55:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <8A87A9A84C201449A0C56B728ACF491E0BA6A9@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceWC1RtzMJy5K2DTwGmXANjr/voFgAF3jWkAABdhRAAAMp2gACzFObAAA7cMHAAbLc/sA==
Thread-topic: [Xen-devel] [Patch] Buffer disk I/O requests
Ian Pratt wrote:
>>> How does it compare to just using the SCSI HBA support that got
>>> checked in a few days ago (in the qemu-dm 0.9.0 upgrade)?
>> In our test,  the performance of SCSI HBA is better than our patch
>> performance in qemu 0.9.0,
> Thanks for running the tests.
>> But we find the total I/O preformance
>> downgrade a lot after upgrade to qemu 0.9.0. We suspect there may be
>> some issues in qemu 0.9.0.
> Please can you explain in more detail.
We just found the preformance is down when we run the same test cases,
but now we don't know why.

>>> If we're going to add support for enabling buffering of ioport
>>> accesses beyond what we currently special case for the VGA it should
>>> be via a generic interface used by qemu to register sets of ports
>>> with xen and configure how they will be handled.
>> Yes, if there are many these buffering cases, using a generic
>> interface is a final solution.
> I'd like to see this generic mechanism introduced for more than just
> whether writes are buffered or not -- it would be very useful to
> register ranges of port or mmio space for handling in different
> fashions, e.g.:
>  * read: forward to handler domain X channel Y
>  * read: read as zeros
>  * write: forward to handler domain X channel Y (and flush any
> buffered) 
>  * write: buffer and forward to domain X channel Y
>  * write: ignore writes
> These hooks would also be very useful for adding debugging/tracing. I
> severely dislike our current  approach of forwarding anything that
> doesn't get picked up in Xen to a single qemu-dm rather than
> registering explicit ranges.
> Best,
> Ian

Agree. A generic mechanism should be introduced in future, because we
have found buffering I/O port or MMIO is valuable. However I think our
patch is still useful now, after all it obviously improves performance
of IDE emulation disk I/O, 

Best regards,

Xen-devel mailing list