On Fri, 2011-03-11 at 16:49 +1030, Rusty Russell wrote: > But if one side outruns the other, it does a lot of unnecessary work > notifying/interrupting it over and over again before the host/guest > gets > a chance to shut notifications/interrupts off. Hence the last_used > publishing patch (Xen does this right, I screwed it up). > > Long weekend here, and I'm otherwise committed. But if noone has > cleaned up that patch by early next week, I'll try to do so and see if > we can make a real difference. This patch doesn't seem to help guest TX queue overrun. I couldn't find any other reason why the TX queue overrun, even I increased guest send queue ring size to 1K, it didn't help at all. I sent out a dropping packet approach for guest to avoid this for you to review. Small message size performance has been dramatically increased with a few packet drops. Most of the workload doesn't invoke the TX queue overrun, so I don't see any regressions. With this patch, vhost side doesn't need to signal guest on TX path, however for previous guest, we still need vhost to signal guest. Please let me know if you have any other ideas to debug what causes guest TX overrun. Thanks Shirley -- 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
