Re: [Xen-users] GPL PV drivers for Windows 0.9.11-pre12

[Juan Pablo Rojas Jiménez <jprojas@xxxxxxxxxxxxxxx>]

In the windows DomU i use a tool called DiskTT... Basically it creates a file of the size you configure and writes and reads it in the number of chunks you say.

For linux you could use DD exactly the same... for example dd if=/dev/zero of=testFile bs=1024 count=1000 (1000 blocks of 1Kb)... It will tell you the write speed...
To test the read speed you could use hdparm  -t|-T  <device> (use --direct to NOT use caches :)

Something i forgot to tell you... read speeds were quite good actually in the xp64 , although also a bit slower than with qemu...

Thanks for the good job, and your response! :)

Juan pablo

James Harper escribió:

I've installed GPL PV drivers in XP64 using 2k3x64 check of 0.9.11-pre13
and everything went fine (functionally)...
    

Thanks for the report.

  

Appart from that, the
performance was actually worst than using the default qemu devices...

I've already sent a message with the config i used but, briefly: dom 0
3x500 - raid5 - lvm partitions for VM disks. 40Mb/s in dom0, 15Mb/s in
xp64 domU with qemu and 4Mb/s enabling /gplpv...

Any clue?

    

No, but there are enough of these reports around that I'm making it a priority to look at next.

Can you tell me what tools you are using for testing?

I know that there is a performance related problem with buffer alignment, although I'm not sure how it relates to real world performance, or if it relates at all to the poor performance that people have been seeing while benchmarking.

Basically, Linux always aligns block device request buffers to a 512 byte (sector) boundary in memory, eg the address of the buffer will always be divisible by 512. The Dom0 xen block device driver backend enforces this too, so I have to comply.

Windows, on the other hand, doesn't care, and only mostly aligns request buffers to a 512 byte boundary, so I have to double buffer the requests (eg copy to (for a write) or from (for a read) a secondary buffer that is aligned to a 512 byte boundary. There are small overheads with this but the main problem is that the secondary buffer is only small and so a large read or write request gets broken down into several requests that must be executed serially, eg part 2 of the request can only be submitted once part 1 has been completed. Fortunately I have only seen Windows issue large numbers of non-aligned requests during format, chkdsk (online and boot) and certain benchmarking tools.

A disk driver under Windows using the scsiport framework (eg xenvbd) executes at a very high IRQ Level, and it is impossible to allocate memory at that IRQL so I'm limited as to what buffers I can make use of.

Sorry you asked? :)

I really would like to know of a simple, easy, and fast tool (eg command line based) to do testing under a Linux DomU and a Windows DomU. It doesn't have to be incredibly accurate, as long as I can make comparisons between the two environments... I find iometer painful :(

Thanks

James

  

Attachment: jprojas.vcf
Description: Vcard

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users