On Thu, Jun 11, 2009 at 12:09:33AM +0930, Rusty Russell wrote: > On Wed, 10 Jun 2009 03:56:31 pm Dor Laor wrote: > > Rusty Russell wrote: > > > The current theoretical hole is that the host suppresses notifications > > > using the VIRTIO_AVAIL_F_NO_NOTIFY flag, but we can get a number of > > > notifications in before it gets to that suppression. You can use a > > > counter to improve this: you only notify when they're equal, and inc when > > > you notify. That way you suppress further notifications even if the > > > other side takes ages to wake up. In practice, this shouldn't be played > > > with until we have full aio (or equiv in kernel) for other side: host > > > xmit tends to be too fast at the moment and we get a notification per > > > packet anyway. > > > > Xen ring has the exact optimization for ages. imho we should have it > > too, regardless of aio. > > It reduces #vmexits/spurious wakeups and it is very simple to implement. > > But look at number of wakeups received vs notifications sent: I just don't see > any benefit there at the moment. As I said, improving the host code might > change that significantly. > > And implementing it the other way is v. v. hard given the nature of interrupts > (shared and coalesced). I agree it's not such a simple thing to implement race-free, so I do buy the argument that we shouldn't unless it gives a performance benefit. But I don't understand how aio will make implementing it easier - or are you merely saying that it will make it worthwhile? -- MST -- 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
