virtualization.lists.linux-foundation.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sasha Levin <levinsasha928@gmail.com>
Cc: markmc@redhat.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH] virtio-ring: Use threshold for switching to indirect descriptors
Date: Sun, 4 Dec 2011 18:22:21 +0200	[thread overview]
Message-ID: <20111204162221.GB22501@redhat.com> (raw)
In-Reply-To: <1323000831.4205.4.camel@lappy>

On Sun, Dec 04, 2011 at 02:13:51PM +0200, Sasha Levin wrote:
> On Sun, 2011-12-04 at 13:52 +0200, Avi Kivity wrote:
> > On 12/03/2011 01:50 PM, Sasha Levin wrote:
> > > On Fri, 2011-12-02 at 11:16 +1030, Rusty Russell wrote:
> > > > On Thu, 1 Dec 2011 12:26:42 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > > > On Thu, Dec 01, 2011 at 10:09:37AM +0200, Sasha Levin wrote:
> > > > > > On Thu, 2011-12-01 at 09:58 +0200, Michael S. Tsirkin wrote:
> > > > > > > We'll presumably need some logic to increment is back,
> > > > > > > to account for random workload changes.
> > > > > > > Something like slow start?
> > > > > > 
> > > > > > We can increment it each time the queue was less than 10% full, it
> > > > > > should act like slow start, no?
> > > > > 
> > > > > No, we really shouldn't get an empty ring as long as things behave
> > > > > well. What I meant is something like:
> > > > 
> > > > I was thinking of the network output case, but you're right.  We need to
> > > > distinguish between usually full (eg. virtio-net input) and usually
> > > > empty (eg. virtio-net output).
> > > > 
> > > > The signal for "we to pack more into the ring" is different.  We could
> > > > use some hacky heuristic like "out == 0" but I'd rather make it explicit
> > > > when we set up the virtqueue.
> > > > 
> > > > Our other alternative, moving the logic to the driver, is worse.
> > > > 
> > > > As to fading the effect over time, that's harder.  We have to deplete
> > > > the ring quite a few times before it turns into always-indirect.  We
> > > > could back off every time the ring is totally idle, but that may hurt
> > > > bursty traffic.  Let's try simple first?
> > >
> > > I tried to take a different approach, and tried putting the indirect
> > > descriptors in a kmem_cache as Michael suggested. The benchmarks showed
> > > that this way virtio-net actually worked faster with indirect on even in
> > > a single stream.
> > 
> > How much better?
> 
> host->guest was same with both indirect on and off, and guest->host went
> up by 5% with indirect on.
> 
> This was just a simple 1 TCP stream test.

I'm confused. didn't you see a bigger benefit for guest->host by
switching indirect off?

> > 
> > I think that if indirects benefit networking, then we're doing something
> > wrong.  What's going on?  Does the ring get filled too early?  If so we
> > should expand it.
> > 
> 
> -- 
> 
> Sasha.

  reply	other threads:[~2011-12-04 16:22 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-29  9:33 [PATCH] virtio-ring: Use threshold for switching to indirect descriptors Sasha Levin
2011-11-29 12:56 ` Michael S. Tsirkin
2011-11-29 13:34   ` Sasha Levin
2011-11-29 13:54     ` Michael S. Tsirkin
     [not found]     ` <20111129135406.GB30966@redhat.com>
2011-11-29 14:21       ` Sasha Levin
2011-11-29 14:54         ` Michael S. Tsirkin
2011-11-29 14:58           ` Avi Kivity
2011-11-30 16:11             ` Sasha Levin
2011-11-30 16:17               ` Sasha Levin
2011-12-01  2:42               ` Rusty Russell
2011-12-01  7:58                 ` Michael S. Tsirkin
2011-12-01  8:09                   ` Sasha Levin
2011-12-01 10:26                     ` Michael S. Tsirkin
2011-12-02  0:46                       ` Rusty Russell
2011-12-03 11:50                         ` Sasha Levin
2011-12-04 11:06                           ` Michael S. Tsirkin
2011-12-04 15:15                             ` Michael S. Tsirkin
2011-12-04 11:52                           ` Avi Kivity
2011-12-04 12:01                             ` Michael S. Tsirkin
2011-12-04 12:06                               ` Avi Kivity
2011-12-04 15:11                                 ` Michael S. Tsirkin
2011-12-04 15:16                                   ` Avi Kivity
2011-12-04 16:00                                     ` Michael S. Tsirkin
2011-12-04 16:33                                       ` Avi Kivity
2011-12-05  0:10                                     ` Rusty Russell
2011-12-05  9:52                                       ` Avi Kivity
2011-12-06  5:07                                         ` Rusty Russell
2011-12-06  9:58                                           ` Avi Kivity
2011-12-06 12:03                                             ` Rusty Russell
     [not found]                                             ` <87pqg1kiuu.fsf@rustcorp.com.au>
2011-12-07 13:37                                               ` Avi Kivity
2011-12-04 12:13                             ` Sasha Levin
2011-12-04 16:22                               ` Michael S. Tsirkin [this message]
2011-12-04 17:34                                 ` Sasha Levin
2011-12-04 17:37                                   ` Avi Kivity
2011-12-04 17:39                                     ` Sasha Levin
2011-12-04 18:23                                       ` Sasha Levin
2011-12-07 14:02                                         ` Sasha Levin
2011-12-07 15:48                                           ` Michael S. Tsirkin
2011-12-08  9:44                                             ` Rusty Russell
     [not found]                                             ` <87r50fgzyj.fsf@rustcorp.com.au>
2011-12-08 10:37                                               ` Sasha Levin
2011-12-09  5:33                                                 ` Rusty Russell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111204162221.GB22501@redhat.com \
    --to=mst@redhat.com \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=levinsasha928@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).