On 09/25/2009 10:53 AM, Kenni Lund wrote:
2009/9/25 Vadim Rozenfeld<vroze...@redhat.com>:
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<ke...@kelu.dk> 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?
I have no idea what was the reason for building and announcing XP 32bit
driver.
I mean, technically it is possible. You can also expect less CPU
consumption by switching
to SCSIPORT virtio driver. But please don't expect any significant
performance burst.
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?
I don't know, but why not? It shouldn't be too complicated.
Best Regards,
Kenni
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
