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

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

  • To: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • 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
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • 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



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