Virtio blk latency

Virtio blk latency

[Esparza Borquez, David]

Hi Stefan,

We are measuring virtio blk latency in linux containers following the method presented by you in 
http://www.linux-kvm.org/page/Virtio/Block/Latency  and we have some questions: 

1. Does a single paio_submit call is followed by a pair of virtio_queue_notify/vitio_notify ? 
or a single paio_submit call could be followed by several virtio_queue_notify/vitio_notify traces.

2. Sometimes Host kvm.ko (kvm_pio:pio_write) traces appear to have less latency than QEMU paio/virtio traces and in theory they should be grater... do you think this is due to the clock we are using in the host/guest? we've tried several combinations of clocks but so far no luck or at least none has been consistent.

3. Because we have not observed results for QEMU paio latency when tracking posix_aio_process_queue( ) , we opted for measuring 'paio' latency but with the event 'paio_submit'. Do you think that could be ok to measure qemu paio latency?

Thank you In advance.

David Esparza.

Re: Virtio blk latency

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]

On Mon, Nov 07, 2016 at 04:43:13PM +0000, Esparza Borquez, David wrote:
> We are measuring virtio blk latency in linux containers following the method presented by you in 
> http://www.linux-kvm.org/page/Virtio/Block/Latency  and we have some questions: 

That page is old but the general approach still makes sense.  Some of
the details (e.g. trace event names) have changed.

I also recommend comparing against blktrace and benchmark I/O statistics
to sanity-check your tracing results.  That way you can be sure that the
numbers you're getting make sense.

> 1. Does a single paio_submit call is followed by a pair of virtio_queue_notify/vitio_notify ? 
> or a single paio_submit call could be followed by several virtio_queue_notify/vitio_notify traces.

It should be:

1 x virtio_queue_notify()
N x paio_submit() (N >= 1, there could be multiple requests to submit)
N x virtio_notify()

Note that the N virtio_notify() calls could happen at any time, even
after the *next* virtio_queue_notify().  This is because virtio-blk
requests can be done in parallel and their lifetimes can overlap.

Note that paio_submit() is used with the defailt -drive aio=threads
option.  If you use -drive aio=native then laio_submit() can be used
instead.

> 2. Sometimes Host kvm.ko (kvm_pio:pio_write) traces appear to have less latency than QEMU paio/virtio traces and in theory they should be grater... do you think this is due to the clock we are using in the host/guest? we've tried several combinations of clocks but so far no luck or at least none has been consistent.

Which tracing backend did you enable in QEMU ./configure?  I'd expect
kvm:kvm_pio and QEMU trace events to use coherent clock sources.

> 3. Because we have not observed results for QEMU paio latency when tracking posix_aio_process_queue( ) , we opted for measuring 'paio' latency but with the event 'paio_submit'. Do you think that could be ok to measure qemu paio latency?

posix_aio_process_queue does not exist in modern QEMU.

Latency is the time between 2 events.  You have only mentioned
paio_submit so I don't know what other event you are using to calculate
the latency.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]