On Fri, 2011-03-18 at 18:41 -0700, Shirley Ma wrote: > > > + /* Drop packet instead of stop queue for better > performance > > */ > > > > I would like to see some justification as to why this is the right > > way to go and not just papering over the real problem. > > Fair. KVM guest virtio_net TX queue stop/restart is pretty expensive, > which involves: > > 1. Guest enable callback: one memory barrier, interrupt flag set Missed this cost: for history reason, it also involves a guest exit from I/O write (PCI_QUEUE_NOTIFY). > 2. Host signals guest: one memory barrier, and a TX interrupt from > host > to KVM guest through evenfd_signal. > > > Most of the workload so far we barely see TX over run, except for > small > messages TCP_STREAM. > > For small message size TCP_STREAM workload, no matter how big the TX > queue size is, it always causes overrun. I even re-enable the TX queue > when it's empty, it still hits TX overrun again and again. > > Somehow KVM guest and host is not in pace on processing small packets. > I > tried to pin each thread to different CPU, it didn't help. So it > didn't > seem to be scheduling related. > > >From the performance results, we can see dramatically performance > gain > with this patch. > > I would like to dig out the real reason why host can't in pace with > guest, but haven't figured it out in month, that's the reason I held > this patch for a while. However if anyone can give me any ideas on how > to debug the real problem, I am willing to try it out. -- 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
