From: Mark McLoughlin <markmc@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 0/6] Kill off the virtio_net tx mitigation timer
Date: Thu, 06 Nov 2008 17:45:15 +0000 [thread overview]
Message-ID: <1225993515.10879.48.camel@blaa> (raw)
In-Reply-To: <490EF141.8040005@redhat.com>
Hi Avi,
Just thinking about your variable window suggestion ...
On Mon, 2008-11-03 at 14:40 +0200, Avi Kivity wrote:
> Mark McLoughlin wrote:
> > On Sun, 2008-11-02 at 11:48 +0200, Avi Kivity wrote:
> >> 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.
> >
>
> If the timer affects latency, then something is very wrong. We're
> lacking an adjustable window.
>
> The way I see it, the notification window should be adjusted according
> to the current workload. If the link is idle, the window should be one
> packet -- notify as soon as something is queued. As the workload
> increases, the window increases to (safety_factor * allowable_latency /
> packet_rate). The timer is set to allowable_latency to catch changes in
> workload.
>
> For example:
>
> - allowable_latency 1ms (implies 1K vmexits/sec desired)
> - current packet_rate 20K packets/sec
> - safety_factor 0.8
>
> So we request notifications every 0.8 * 20K * 1m = 16 packets, and set
> the timer to 1ms. Usually we get a notification every 16 packets, just
> before timer expiration. If the workload increases, we get
> notifications sooner, so we increase the window. If the workload drops,
> the timer fires and we decrease the window.
>
> The timer should never fire on an all-out benchmark, or in a ping test.
The way I see this (continuing with your example figures) playing out
is:
- If we have a packet rate of <2.5K packets/sec, we essentially have
zero added latency - each packet causes a vmexit and the packet is
dispatched immediately
- As soon as we go above 2.5k we add, on average, an additional
~400us delay to each packet
- This is almost identical to our current scheme with an 800us timer,
except that flushes are typically triggered by a vmexit instead of
the timer expiring
I don't think this is the effect you're looking for? Am I missing
something?
Cheers,
Mark.
next prev parent reply other threads:[~2008-11-06 17:46 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-30 17:51 [PATCH 0/6] Kill off the virtio_net tx mitigation timer Mark McLoughlin
2008-10-30 17:51 ` [PATCH 1/6] kvm: qemu: virtio: remove unused variable Mark McLoughlin
2008-10-30 17:51 ` [PATCH 2/6] kvm: qemu: dup the qemu_eventfd() return Mark McLoughlin
2008-10-30 17:51 ` [PATCH 3/6] kvm: qemu: add qemu_eventfd_write() and qemu_eventfd_read() Mark McLoughlin
2008-10-30 17:51 ` [PATCH 4/6] kvm: qemu: aggregate reads from eventfd Mark McLoughlin
2008-10-30 17:51 ` [PATCH 5/6] kvm: qemu: virtio-net: handle all tx in I/O thread without timer Mark McLoughlin
2008-10-30 17:51 ` [PATCH 6/6] kvm: qemu: virtio-net: drop mutex during tx tapfd write Mark McLoughlin
2008-11-04 11:43 ` Avi Kivity
2008-10-30 19:24 ` [PATCH 5/6] kvm: qemu: virtio-net: handle all tx in I/O thread without timer Anthony Liguori
2008-10-31 9:16 ` Mark McLoughlin
2008-11-03 15:07 ` Mark McLoughlin
2008-11-02 9:56 ` Avi Kivity
2008-11-04 15:23 ` David S. Ahern
2008-11-06 17:02 ` Mark McLoughlin
2008-11-06 17:13 ` David S. Ahern
2008-11-06 17:43 ` Avi Kivity
2008-10-30 19:20 ` [PATCH 0/6] Kill off the virtio_net tx mitigation timer Anthony Liguori
2008-11-02 9:48 ` Avi Kivity
2008-11-03 12:23 ` Mark McLoughlin
2008-11-03 12:40 ` Avi Kivity
2008-11-03 15:04 ` Mark McLoughlin
2008-11-03 15:19 ` Avi Kivity
2008-11-06 16:46 ` Mark McLoughlin
2008-11-06 17:38 ` Avi Kivity
2008-11-06 17:45 ` Mark McLoughlin [this message]
2008-11-09 11:29 ` Avi Kivity
2008-11-02 9:57 ` Avi Kivity
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=1225993515.10879.48.camel@blaa \
--to=markmc@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.