[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [vfio-users] Speed tips requested

On Sun, 2017-03-26 at 08:31 -0600, Alex Williamson wrote:
> On Sun, Mar 26, 2017 at 4:33 AM, Patrick O'Callaghan <poc 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.  QCOW is
> generally recommended when on disk image size is a concern or you want
> advanced features like backing images, snapshots, etc.  I think real world
> performance of QCOW is noticeably worse than the recommended image types.
> Also, be careful with caching, it's easy to get into a situation where the
> benchmark shows it to be great, sometime unbelievably so, but perhaps at
> the cost of safe operation or to the determent of overall system behavior.
> For example, do you really want to sacrifice buffer cache in the host for
> the benefit of the guest.  Thanks,

Understood. I converted from raw to qcow2 and it was no worse for speed
in my use case (in fact it felt subjectively a little faster), and the
ability to do snapshots does interest me.

No-one has commented on the keyboard overrun issue I asked about.
That's really more noticeable at this stage than file I/O. I moved the
wireless hub to a USB-3 port and again it may have made a slight
difference, but some stuttering still occurs, i.e. holding down a key
will quite quickly (say 5 seconds ballpark) fill the input buffer and
generate an audio buzz.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]