[Virtio-fs] xfstest results for virtio-fs on aarch64

[Stefan Hajnoczi]

On Thu, Oct 17, 2019 at 04:36:33AM +0900, Chirantan Ekbote wrote:
> On Wed, Oct 16, 2019 at 11:10 PM Stefan Hajnoczi <stefanha at redhat.com> wrote:
> >
> > On Tue, Oct 15, 2019 at 11:58:46PM +0900, Chirantan Ekbote wrote:
> > >
> > > As for the performance numbers, I don't have my test device with me
> > > but if I remember correctly the blogbench scores almost doubled when
> > > going from one queue to two queues.
> >
> > If I understand the code correctly each virtqueue is processed by a
> > worker and the number of virtqueues is the vcpu count.  This means that
> > requests are processed in a blocking fashion and the disk is unlikely to
> > reach its maximum queue depth (e.g. often 64 requests).
> >
> > Going from 1 virtqueue to 2 virtqueues will improve performance, but
> > it's still a far cry from the maximum queue depth that the host kernel
> > and hardware supports.  This is why virtiofsd processes multiple
> > requests in parallel on a single virtqueue using a thread pool.
> 
> Hmm, maybe I'm missing something but isn't this still limited by the
> number of requests that can fit in the virtqueue?

Yes, but not a practical issue.  The maximum virtqueue size is chosen by
the VIRTIO device.  QEMU sets it to 128 and that's larger than the
typical queue depth of a disk.  So in practice the virtqueue size is not
the bottleneck.

It makes sense to set the number of virtqueues to the number of vCPUs to
achieve good CPU and interrupt scalability, but this number will be
lower than the disk's queue depth.  So in order to saturate the disk
it's necessary to process a virtqueue's requests in parallel (e.g.
thread pool, aio, etc).

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20191017/f6dcbd78/attachment.sig>