[vfio-users] Speed tips requested

[Zachary Boley]

>From what I've read Red Hat recommends virtio with raw on no cache with io
thread due to the reasons listed above. Not sure about LVM but they did
also say (or someone did) do not use BTRFS for keeping the image.

The only optimization I would immediately recommended is to do
host-passthrough as the CPU option in your guests xml. It's noticeably
different assuming you haven't already done it

On Mar 26, 2017 11:13 AM, "Bronek Kozicki" <brok at spamcop.net> wrote:

> On 26/03/2017 15:31, Alex Williamson wrote:
>
>> On Sun, Mar 26, 2017 at 4:33 AM, Patrick O'Callaghan <poc at usb.ve
>> <mailto:poc at usb.ve>> wrote:
>>
>>     On Sun, 2017-03-26 at 10:58 +0100, Bronek Kozicki wrote:
>>     > Assuming you use libvirt, make sure to use vCPU pinning. For disk
>> access, try cache='writeback' io='threads'. If you switch to scsio-vfio,
>> this will give you the ability to define queue length which might
>> additionally improve IO. Also, try QCOW2 format for guest disk, it might
>> enable some additional optimizations. However given you host seem to have
>> little spare capacity, YMMV
>>
>>     Thanks. I'm already using CPU pinning as I said. The disk options are
>>     both set to "hypervisor default" so I'll try changing them. I'd
>>     configured the guest disk as 'raw' assuming that would be faster than
>>     QCOW2 but I'll look into it.
>>
>>
>>
>> Generally the recommendation is to use raw (not sparse), LVM, or a block
>> device for the best performance.  QCOW is never going to be as fast as
>> these at writing unused blocks since it needs to go out and allocate new
>> blocks from the underlying file system when this happens.
>>
>
> I am not going to argue with your experience here, only wanted to note
> that QCOW2 can be created with preallcation=falloc (or full, which is not
> very useful) which means there will no extra allocations in the rutime.
> Everything will be allocated at the moment of disk creation with qemu-img
> create -f qcow2 -o preallcation=falloc ....
>
>
>
> B.
>
> _______________________________________________
> vfio-users mailing list
> vfio-users at redhat.com
> https://www.redhat.com/mailman/listinfo/vfio-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20170326/1a6b3f94/attachment.htm>