From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark McLoughlin Subject: Re: [PATCH 0/6] Kill off the virtio_net tx mitigation timer Date: Mon, 03 Nov 2008 12:23:29 +0000 Message-ID: <1225715009.5904.39.camel@blaa> References: <> <1225389113-28332-1-git-send-email-markmc@redhat.com> <490D7754.4070807@redhat.com> Reply-To: Mark McLoughlin Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:43820 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754067AbYKCMY3 (ORCPT ); Mon, 3 Nov 2008 07:24:29 -0500 In-Reply-To: <490D7754.4070807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.