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

RE: [Xen-devel][PATCH][VT] Multithread IDE device model ( was: RE: [Xen-devel] [PATCH]Make IDE dma tranfer run in another thread inqemu)


  • To: "Anthony Liguori" <aliguori@xxxxxxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Thu, 27 Oct 2005 22:18:24 +0800
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Yang, Xiaowei" <xiaowei.yang@xxxxxxxxx>
  • Delivery-date: Thu, 27 Oct 2005 14:15:46 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcXaeWa43U5287YRSji8XwrXK2tdrAAhXfLQ
  • Thread-topic: [Xen-devel][PATCH][VT] Multithread IDE device model ( was: RE: [Xen-devel] [PATCH]Make IDE dma tranfer run in another thread inqemu)

Anthony:
        Thanks for your information.
        The DMA patch in the qemu site  is to extend the "Windows 2000
Install Hack" to work for DMA, the current qemu in Xen is already DMA
enabled. The non blocking IO patch there is similar with the one we sent
out for Xen. Yes maybe in future we need to rebase Xen/Qemu to latest
Qemu version, but it is dangerous to do now as Xen/3.0 release is
coming. So after discussing with Jun, we think it is better to keep
those rebase to be done after Xen 3.0.
        For the performance data, the patch listed in Qemu site
mentioned about 20% improvement in a situation where a CPU-intensive
thread was competing with an IO-intensive thread. Formal test with our
IDE multithread patch show:
        "cp -a linux-2.6.12 backup"  get 30% up
        "tar xjf linux-2.6.12.tar.bz2" get 47% up
        "hdparam -t /dev/hda1" get 48% up.
        "Kernel build" get 8-14% up
        So, I think we can stick with current situation now, and revist
later when we rebase Qemu.
Keir:
        I just reattach the patch.
Thanks
        
Signed-off-by: Ke Yu <ke.yu@xxxxxxxxx>
Signed-off-by: Xiaowei Yang <xiaowei.yang@xxxxxxxxx>

Anthony Liguori wrote:
> Dong, Eddie wrote:
> 
>> Hi Anthony:
>>      I think you made misunderstanding to this patch. Current Qemu in
>> Xen is already DMA enabled. If I remembered correctly, it happens
>> since we change DM from Bochs to Qemu.
>>      Without this patch, guest IO operation that trigger DMA (like
>> port 0xc000 write) will wait in Qemu till the DMA operation is
>> completed, that is original single thread IDE device model mean.
>>      With this patch, a seperate thread will service the dma
>> operation started by IO operation, and interrupt target processor
>> when it is completed, while the main thread can rapidly return to
>> guest (like 0xc000 write). 
>> 
>> 
> Yup, the site I linked to has two patches: a DMA patch and a
> concurrent IO patch.
> 
> Here's a direct link:
>
http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_concurrent_io.patch
> 
> It's using the same basic approach as your patch (another thread waits
> for completion of IO event).  I'm pointing it out though in case
> there's a desire to stay closer to QEMU upstream when possible. 
> Might enable more code sharing in the future.
> 
> Regards,
> 
> Anthony Liguori
> 
>> Thanks,eddie
>> 
>> Anthony Liguori wrote:
>> 
>> 
>>> Hi Eddie,
>>> 
>>> There was a patch floating around on qemu-devel recently to make IDE
>>> DMA concurrent.  Fabrice is planning to include it in QEMU as long
>>> as there are no regressions.  It may already be in CVS.
>>> 
>>> See
>>> http://people.brandeis.edu/~jcoiner/qemu_idedma/qemu_dma_patch.html
>>> 
>>> The reported performance improvement IO is up to 20% so it's
>>> definitely worth applying... 
>>> 
>>> Regards,
>>> 
>>> Anthony Liguori

Attachment: ide_mt.patch
Description: ide_mt.patch

_______________________________________________
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®.