Re: [Patch] Buffer disk I/O requests

[Anthony Liguori <aliguori@us.ibm.com>]

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. 

IDE emulation is largely bound by how many requests you can get our per 
second.  In 0.8.2, DMA completion happened immediately after the IO 
request finished.  In 0.9.0, DMA completion is triggered by a AIO 
completion of the event.  This implies a trip through the main event loop.

By default, QEMU only allows glibc AIO to use a single thread which 
basically turns all AIO requests into synchronous requests.  You'll get 
some performance back by changing that to allow multiple threads.

I haven't looked at the QEMU 0.9.0 port just yet but I suspect that's 
the problem since I've seen this behavior in normal QEMU.

Regards,

Anthony Liguori

>>> 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
> 
> 
> 
>  
> 
> 
> 
>