2009/9/25 Vadim Rozenfeld <vrozenfe@xxxxxxxxxx>: > On 09/25/2009 12:07 AM, Dor Laor wrote: >> >> On 09/24/2009 11:59 PM, Javier Guerra wrote: >>> >>> On Thu, Sep 24, 2009 at 3:38 PM, Kenni Lund<kenni@xxxxxxx> wrote: >>>> >>>> I've done some benchmarking with the drivers on Windows XP SP3 32bit, >>>> but it seems like using the VirtIO drivers are slower than the IDE >>>> drivers in >>>> (almost) all cases. Perhaps I've missed something or does the driver >>>> still >>>> need optimization? >>> >>> very interesting! >>> >>> it seems that IDE wins on all the performance numbers, but VirtIO >>> always has lower CPU utilization. i guess this is guest CPU %, right? >>> it would also be interesting to compare the CPU usage from the host >>> point of view, since a lower 'off-guest' CPU usage is very important >>> for scaling to many guests doing I/O. >>> >> These drivers are mainly tweaked for win2k3 and win2k8. We once had queue >> depth settings in the driver, not sure we still have it, Vadim, can you add >> more info? >> Dor > > Windows XP 32-bit virtio block driver was created from our mainline code > almost for fun. > Not like our mainline code, which is STORPORT oriented, it is a SCSIPORT > (!!!!) mini-port driver. > SCSIPORT has never been known as I/O optimized storage stack. > SCSIPORT architecture is almost dead officially. > Windows XP 32-bit has no support for STORPORT or virtual storage stack. Ok, in that case, wouldn't it be better simply not to build the XP driver and instead put a note somewhere (in the wiki?), saying that it doesn't make sense to use VirtIO on XP due to these reasons? > Developing monolithic disk driver, which will sit right on top of virtio-blk > PCI device, looks like the one way > to have some kind of high throughput storage for Windows XP 32-bit. Ok, since these drivers are targeted Windows Server and XP is getting old, I suppose no efforts will be put into developing such driver, or? Best Regards, Kenni -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
