Best way to busy-wait for a virtio queue?

Best way to busy-wait for a virtio queue?

[H. Peter Anvin]

Is there any preferred way to busy-wait on a virtio event?  As in: the
guest doesn't have anything useful to do until something is plopped down
on the virtio queue, but would like to proceed as quickly as possible
after that.  Passing through an interrupt handler seems like unnecessary
overhead.

Right now I have a poll loop looking like (pseudocode):

outw(0, trigger);
while (readl(ring->output pointer) != final output pointer)
	cpu_relax();		/* x86 PAUSE instruction */

... but I have no idea how much sense that makes.


	-hpa

Re: Best way to busy-wait for a virtio queue?

[Eric Northup]

On Fri, Mar 29, 2013 at 4:12 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Is there any preferred way to busy-wait on a virtio event?  As in: the
> guest doesn't have anything useful to do until something is plopped down
> on the virtio queue, but would like to proceed as quickly as possible
> after that.  Passing through an interrupt handler seems like unnecessary
> overhead.

How much information do you have about the host?  It is possible that
leaving the vCPU running is displacing execution from whatever host
thread(s) would be involved in making progress towards the event you
want delivered - in that case, the interrupt overhead might be
balanced out by lower latency of the event delivery.

> Right now I have a poll loop looking like (pseudocode):
>
> outw(0, trigger);
> while (readl(ring->output pointer) != final output pointer)
>         cpu_relax();            /* x86 PAUSE instruction */
>
> ... but I have no idea how much sense that makes.

The cleanest expression of the desired semantic I can think of would
be MONITOR/MWAIT, except that KVM doesn't allow those instructions in
the guest.  For the case of a 100% non-overcommitted host (including
host i/o processing), there's no reason not to allow the guest to run
those instructions.

Lacking that, I think the above busy-loop w/PAUSE in it will end up
causing a pause-loop exit - so it has largely the same effect but also
works on current hosts.