[vfio-users] Speed tips requested

[Nick Sarnie]

Sorry, is that a SCSI controller set to virtio type, or the virtio option
selected for the disk instead of SCSI? I've seen both recommended.

Thanks,
Sarnex

On Sun, Mar 26, 2017 at 12:58 PM, Zachary Boley <zboley00 at gmail.com> wrote:

> 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
>>
>
> _______________________________________________
> 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/b6457c4d/attachment.htm>