On Sun, 2008-11-02 at 11:48 +0200, Avi Kivity wrote: > Mark McLoughlin wrote: > > Hey, > > > > The main patch in this series is 5/6 - it just kills off the > > virtio_net tx mitigation timer and does all the tx I/O in the > > I/O thread. > > > > > > What will it do to small packet, multi-flow loads (simulated by ping -f > -l 30 $external)?
It should improve the latency - the packets will be flushed more quickly than the 150us timeout without blocking the guest. I've a crappy external network setup locally atm, so the improvement for guest->external gets lost in the noise there, but it does show up with that workload and guest->host. > Where does the benefit come from? There are two things going on here, I think. First is that the timer affects latency, removing the timeout helps that. Second is that currently when we fill up the ring we block the guest vcpu and flush. Thus, while we're copying a entire ring full of packets that guest isn't making progress. Doing the copying in the I/O thread helps there. Note - the only net I/O we currently do in the vcpu thread at the moment is when the guest is saturating the link. Any other timer, all the I/O is done in the I/O thread by virtue of the timer. > Is the overhead of managing the timer too high, or does it fire too > late and so we sleep? If the latter, can we tune it dynamically? > > For example, if the guest sees it is making a lot of progress without > the host catching up (waiting on the tx timer), it can > kick_I_really_mean_this_now(), to get the host to notice. It does that already - if the ring fills up the guests forces a kick which causes the host to flush the ring in the vcpu thread. Cheers, Mark. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
