Best way to busy-wait for a virtio queue?
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
Quoted 6 lines · 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.
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.
Quoted 7 lines
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.