Mark McLoughlin wrote:
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
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 th
Mark McLoughlin wrote:
Hey,
So, I went off and spent some time gathering more data on this stuff
and putting it together in a more consumable fashion.
Here are some graphs showing the effect some of these changes have on
throughput, cpu utilization and vmexit rate:
http://mark
Hey,
So, I went off and spent some time gathering more data on this stuff
and putting it together in a more consumable fashion.
Here are some graphs showing the effect some of these changes have on
throughput, cpu utilization and vmexit rate:
http://markmc.fedorapeople.org/virti
Mark McLoughlin wrote:
But it will increase overhead, since suddenly we aren't queueing
anymore. One vmexit per small packet.
Yes in theory, but the packet copies are acting to mitigate exits since
we don't re-enable notifications again until we're sure the ring is
empty.
You mean, t
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:
> >
> >> Mark McLoughlin wrote:
> >>> 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 i
Mark McLoughlin wrote:
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, mul
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 l
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.
Below are the results I got from benchmarking guest->host and
host->guest on my machine.
There's enough numbers there to make anyon
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)?
Where does the benefit come from?
On Thu, 2008-10-30 at 14:20 -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
> > | guest->host tput |
> > host->guest tput
> > netperf, 10x20s runs (Gb/s) |min/ mean/ max/stddev | min/
> > mean/ max/stddev
> >
> > ---
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.
Below are the results I got from benchmarking guest->host and
host->guest on my machine.
There's enough numbers there to make anyon
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.
Below are the results I got from benchmarking guest->host and
host->guest on my machine.
There's enough numbers there to make anyone blind, but basically
t
13 matches
Mail list logo
