On Fri, Mar 29, 2013 at 4:12 PM, H. Peter Anvin <hpa@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
