* CFP: ACM Symposium on High-Performance Parallel and Distributed Computing (HPDC'12)
From: Ioan Raicu @ 2011-12-15 13:46 UTC (permalink / raw)
To: virtualization
**** CALL FOR PAPERS ****
The 21st International ACM Symposium on
High-Performance Parallel and Distributed Computing
(HPDC'12)
Delft University of Technology, Delft, the Netherlands
June 18-22, 2012
http://www.hpdc.org/2012
The ACM International Symposium on High-Performance Parallel and Distributed Computing (HPDC)
is the premier annual conference on the design, the implementation, the evaluation, and
the use of parallel and distributed systems for high-end computing. HPDC'12 will take place
in Delft, the Netherlands, a historical, picturesque city that is less than one hour away
from Amsterdam-Schiphol airport. The conference will be held on June 20-22 (Wednesday to
Friday), with affiliated workshops taking place on June 18-19 (Monday and Tuesday).
**** SUBMISSION DEADLINES ****
Abstracts: 16 January 2012
Papers: 23 January 2012 (No extensions!)
**** HPDC'12 GENERAL CHAIR ****
Dick Epema, Delft University of Technology, Delft, the Netherlands
**** HPDC'12 PROGRAM CO-CHAIRS ****
Thilo Kielmann, Vrije Universiteit, Amsterdam, the Netherlands
Matei Ripeanu, The University of British Columbia, Vancouver, Canada
**** HPDC'12 WORKSHOPS CHAIR ****
Alexandru Iosup, Delft University of Technology, Delft, the Netherlands
**** SCOPE AND TOPICS ****
Submissions are welcomed on all forms of high-performance parallel and distributed computing,
including but not limited to clusters, clouds, grids, utility computing, data-intensive
computing, and massively multicore systems. Submissions that explore solutions to estimate
and reduce the energy footprint of such systems are particularly encouraged. All papers
will be evaluated for their originality, potential impact, correctness, quality of
presentation, appropriate presentation of related work, and relevance to the conference,
with a strong preference for rigorous results obtained in operational parallel and
distributed systems.
The topics of interest of the conference include, but are not limited to, the following,
in the context of high-performance parallel and distributed computing:
- Systems, networks, and architectures for high-end computing
- Massively multicore systems
- Virtualization of machines, networks, and storage
- Programming languages and environments
- I/O, storage systems, and data management
- Resource management, energy and cost minimizations
- Performance modeling and analysis
- Fault tolerance, reliability, and availability
- Data-intensive computing
- Applications of parallel and distributed computing
**** PAPER SUBMISSION GUIDELINES ****
Authors are invited to submit technical papers of at most 12 pages in PDF format, including
figures and references. Papers should be formatted in the ACM Proceedings Style and
submitted via the conference web site. No changes to the margins, spacing, or font sizes as
specified by the style file are allowed. Accepted papers will appear in the conference
proceedings, and will be incorporated into the ACM Digital Library. A limited number of
papers will be accepted as posters.
Papers must be self-contained and provide the technical substance required for the program
committee to evaluate their contributions. Submitted papers must be original work that has
not appeared in and is not under consideration for another conference or a journal. See the
ACM Prior Publication Policy for more details.
**** IMPORTANT DATES ****
Abstracts Due: 16 January 2012
Papers Due: 23 January 2012 (No extensions!)
Reviews Released to Authors: 8 March 2012
Author Rebuttals Due: 12 March 2012
Author Notifications: 19 March 2012
Final Papers Due: 16 April 2012
Conference Dates: 18-22 June 2012
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* Re: [PATCH v5 00/11] virtio: s4 support
From: Amit Shah @ 2011-12-15 14:55 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, linux-pm, levinsasha928, Virtualization List
In-Reply-To: <20111215131314.GA22791@redhat.com>
On (Thu) 15 Dec 2011 [15:13:14], Michael S. Tsirkin wrote:
> On Thu, Dec 15, 2011 at 06:15:46PM +0530, Amit Shah wrote:
> > Hi,
> >
> > These patches add support for S4 to virtio (pci) and all drivers.
> >
> > Michael saw some race in virtio-net module removal which will need a
> > similar fix for the freeze code as well. I'll update the virtio-net
> > patch with that fix once the fix is settled upon and applied.
>
> block too?
Right.
Amit
^ permalink raw reply
* Re: [net-next RFC PATCH 0/5] Series short description
From: Rusty Russell @ 2011-12-15 23:12 UTC (permalink / raw)
To: Ben Hutchings
Cc: krkumar2, kvm, mst, netdev, virtualization, levinsasha928, davem
In-Reply-To: <1323913005.2753.47.camel@bwh-desktop>
On Thu, 15 Dec 2011 01:36:44 +0000, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Fri, 2011-12-09 at 16:01 +1030, Rusty Russell wrote:
> > On Wed, 7 Dec 2011 17:02:04 +0000, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > > Most multi-queue controllers could support a kind of hash-based
> > > filtering for TCP/IP by adjusting the RSS indirection table. However,
> > > this table is usually quite small (64-256 entries). This means that
> > > hash collisions will be quite common and this can result in reordering.
> > > The same applies to the small table Jason has proposed for virtio-net.
> >
> > But this happens on real hardware today. Better that real hardware is
> > nice, but is it overkill?
>
> What do you mean, it happens on real hardware today? So far as I know,
> the only cases where we have dynamic adjustment of flow steering are in
> ixgbe (big table of hash filters, I think) and sfc (perfect filters).
> I don't think that anyone's currently doing flow steering with the RSS
> indirection table. (At least, not on Linux. I think that Microsoft was
> intending to do so on Windows, but I don't know whether they ever did.)
Thanks, I missed the word "could".
> > And can't you reorder even with perfect matching, since prior packets
> > will be on the old queue and more recent ones on the new queue? Does it
> > discard or requeue old ones? Or am I missing a trick?
>
> Yes, that is possible. RFS is careful to avoid such reordering by only
> changing the steering of a flow when none of its packets can be in a
> software receive queue. It is not generally possible to do the same for
> hardware receive queues. However, when the first condition is met it is
> likely that there won't be a whole lot of packets for that flow in the
> hardware receive queue either. (But if there are, then I think as a
> side-effect of commit 09994d1 RFS will repeatedly ask the driver to
> steer the flow. Which isn't ideal.)
Should be easy to test, but the question is, how hard should we fight to
maintain ordering? Dave?
It comes down to this. We can say in the spec that a virtio nic which
offers VIRTIO_F_NET_RFS:
1) Must do a perfect matching, with perfect ordering. This means you need
perfect filters, and handle inter-queue ordering if you change a
filter (requeue packets?)
2) Must do a perfect matching, but don't worry about ordering across changes.
3) Best effort matching, with perfect ordering.
3) Best effort matching, best effort ordering.
For a perfect filtering setup, the virtio nic needs to either say how
many filter slots it has, or have a way to fail an RFS request. For
best effort, you can simply ignore RFS requests or accept hash
collisions, without bothering the guest driver at all.
Thanks,
Rusty.
^ permalink raw reply
* Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
From: Rusty Russell @ 2011-12-16 1:50 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sasha Levin, virtualization
In-Reply-To: <20111215063004.GA3630@redhat.com>
On Thu, 15 Dec 2011 10:27:50 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
> I mean like this in block:
>
>
>
> /* Host must always specify the capacity. */
> vdev->config->get(vdev, offsetof(struct virtio_blk_config,
> capacity),
> &capacity, sizeof(capacity));
>
> /* If capacity is too big, truncate with warning. */
> if ((sector_t)capacity != capacity) {
> dev_warn(&vdev->dev, "Capacity %llu too large:
> truncating\n",
> (unsigned long long)capacity);
> capacity = (sector_t)-1;
> }
>
>
> Now let's assume capacity field is changed from 0x8000 to 0x10000
> on host. Is it possible that we read two upper bytes
> before the change so we see 0x0000....
> and 2 lower bytes after the change
> so we see 0x....0000 and resulting capacity appears
> to be 0?
>
> If no why not?
Same issue in reverse with the guest setting the MAC address in
virtio_net, if the host were reading it. And virtio_balloon? We have
ignored it, so far.
Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
appears and vanishes around config writes by either side? Kind of a
hack though...
Cheers,
Rusty.
^ permalink raw reply
* Re: [RFC 3/11] pci: add pci_iomap_range
From: Rusty Russell @ 2011-12-16 1:56 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sasha Levin, virtualization
In-Reply-To: <20111215083048.GB3630@redhat.com>
On Thu, 15 Dec 2011 10:30:49 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Thu, Dec 08, 2011 at 09:02:46PM +1030, Rusty Russell wrote:
> > From: Michael S Tsirkin <mst@redhat.com>
> >
> > Virtio drivers should map the part of the range they need, not necessarily
> > all of it.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
>
> I think that we should add a forcenocache flag.
> This will let devices put the cap structure in
> the prefetcheable BAR. That has an advantage that
> it can be located anywhere in the 2^64 space,
> while non-prefetcheable BARs are limited to lower 4G
> for devices behind a PCI-to-PCI bridge.
OK, want to respin that patch (or patch on top and I'll fold?)
Thanks,
Rusty.
^ permalink raw reply
* Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
From: Rusty Russell @ 2011-12-16 1:58 UTC (permalink / raw)
To: Don Dutile, Michael S. Tsirkin; +Cc: Sasha Levin, virtualization
In-Reply-To: <4EE64380.2090305@redhat.com>
On Mon, 12 Dec 2011 13:10:08 -0500, Don Dutile <ddutile@redhat.com> wrote:
> On 12/12/2011 06:49 AM, Michael S. Tsirkin wrote:
> > On Mon, Dec 12, 2011 at 09:15:03AM +1030, Rusty Russell wrote:
> >> On Sun, 11 Dec 2011 11:42:56 +0200, "Michael S. Tsirkin"<mst@redhat.com> wrote:
> >>> On Thu, Dec 08, 2011 at 09:09:33PM +1030, Rusty Russell wrote:
> >>>> +/* There is no iowrite64. We use two 32-bit ops. */
> >>>> +static void iowrite64(u64 val, const __le64 *addr)
> >>>> +{
> >>>> + iowrite32((u32)val, (__le32 *)addr);
> >>>> + iowrite32(val>> 32, (__le32 *)addr + 1);
> >>>> +}
> >>>> +
> >>>
> >>> Let's put addr_lo/addr_hi in the structure then,
> >>> to make the fact this field is not atomic explicit?
> >>
> >> Good point, assuming I haven't missed something.
> >>
> >> Are 64-bit accesses actually unknown in PCI-land? Or is this a limited
> >> availability thing?
> >>
> >> Thanks,
> >> Rusty.
> >
> > I think PCI can optionally support atomic 64 bit accesses, but not all
> > architectures can generate them.
> >
> yes. PCI(e) support atomic 64-bit ops; it's dependent on CPU & chipset interface
> to PCI that determines ability to generate a 64-bit length xaction.
Does this mean it's possible to detect inside Linux? I'd like to use it
if we can, but if everyone is really going to do two 32 bit writes, then
we should just define it that way.
Thanks,
Rusty.
^ permalink raw reply
* [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: wusongwei, kvm, mst, netdev, hanweidong, virtualization,
xiaowei.yang, Hongyong Zang, levinsasha928
From: Hongyong Zang <zanghongyong@huawei.com>
Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
to translate GPA to HVA. Since kernel's kvm structure already maintains the
address relationship in its member *kvm_memslots*, these patches use kernel's
kvm_memslots directly without the need of initialization and maintenance of
vhost_memory.
Hongyong Zang (2):
kvm: Introduce get_kvm_from_task
vhost-net: Use kvm_memslots for address translation
drivers/vhost/vhost.c | 53 +++++++++++++++++----------------------------
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 13 +++++++++++
3 files changed, 34 insertions(+), 34 deletions(-)
^ permalink raw reply
* [PATCH 1/2] kvm: Introduce get_kvm_from_task
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: wusongwei, kvm, mst, netdev, hanweidong, virtualization,
xiaowei.yang, Hongyong Zang, levinsasha928
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
From: Hongyong Zang <zanghongyong@huawei.com>
This function finds the kvm structure from its corresponding user
space process, such as qemu process.
Signed-off-by: Hongyong Zang <zanghongyong@huawei.com>
---
include/linux/kvm_host.h | 2 +-
virt/kvm/kvm_main.c | 13 +++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 8c5c303..1b2f027 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -801,4 +801,4 @@ static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
}
#endif
-
+struct kvm *get_kvm_from_task(struct task_struct *task);
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e289486..458fe29 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2664,6 +2664,19 @@ static const struct file_operations *stat_fops[] = {
[KVM_STAT_VM] = &vm_stat_fops,
};
+struct kvm* get_kvm_from_task(struct task_struct *task)
+{
+ struct kvm *kvm;
+
+ list_for_each_entry(kvm, &vm_list, vm_list) {
+ if(kvm->mm == task->mm)
+ return kvm;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(get_kvm_from_task);
+
static void kvm_init_debug(void)
{
struct kvm_stats_debugfs_item *p;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] vhost-net: Use kvm_memslots for address translation
From: zanghongyong @ 2011-12-16 5:32 UTC (permalink / raw)
To: linux-kernel
Cc: wusongwei, kvm, mst, netdev, hanweidong, virtualization,
xiaowei.yang, Hongyong Zang, levinsasha928
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
From: Hongyong Zang <zanghongyong@huawei.com>
Use kvm's memslots instead of vhost_memory to traslate address
from GPA to HVA.
Signed-off-by: Hongyong Zang <zanghongyong@huawei.com>
---
drivers/vhost/vhost.c | 53 ++++++++++++++++++------------------------------
1 files changed, 20 insertions(+), 33 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index c14c42b..63e4322 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -11,6 +11,7 @@
* Generic code for virtio server in host kernel.
*/
+#include <linux/kvm_host.h>
#include <linux/eventfd.h>
#include <linux/vhost.h>
#include <linux/virtio_net.h>
@@ -904,23 +905,6 @@ done:
return r;
}
-static const struct vhost_memory_region *find_region(struct vhost_memory *mem,
- __u64 addr, __u32 len)
-{
- struct vhost_memory_region *reg;
- int i;
-
- /* linear search is not brilliant, but we really have on the order of 6
- * regions in practice */
- for (i = 0; i < mem->nregions; ++i) {
- reg = mem->regions + i;
- if (reg->guest_phys_addr <= addr &&
- reg->guest_phys_addr + reg->memory_size - 1 >= addr)
- return reg;
- }
- return NULL;
-}
-
/* TODO: This is really inefficient. We need something like get_user()
* (instruction directly accesses the data, with an exception table entry
* returning -EFAULT). See Documentation/x86/exception-tables.txt.
@@ -1046,40 +1030,36 @@ int vhost_init_used(struct vhost_virtqueue *vq)
return get_user(vq->last_used_idx, &vq->used->idx);
}
-static int translate_desc(struct vhost_dev *dev, u64 addr, u32 len,
+static int translate_desc(struct kvm *kvm, u64 addr, u32 len,
struct iovec iov[], int iov_size)
{
- const struct vhost_memory_region *reg;
- struct vhost_memory *mem;
+ const struct kvm_memory_slot *slot;
+ gfn_t gfn = addr >> PAGE_SHIFT;
struct iovec *_iov;
u64 s = 0;
int ret = 0;
- rcu_read_lock();
-
- mem = rcu_dereference(dev->memory);
while ((u64)len > s) {
u64 size;
if (unlikely(ret >= iov_size)) {
ret = -ENOBUFS;
break;
}
- reg = find_region(mem, addr, len);
- if (unlikely(!reg)) {
+ slot = gfn_to_memslot(kvm, gfn);
+ if (unlikely(!slot)) {
ret = -EFAULT;
break;
}
_iov = iov + ret;
- size = reg->memory_size - addr + reg->guest_phys_addr;
+ size = slot->npages*VHOST_PAGE_SIZE - addr + (slot->base_gfn<<PAGE_SHIFT);
_iov->iov_len = min((u64)len, size);
_iov->iov_base = (void __user *)(unsigned long)
- (reg->userspace_addr + addr - reg->guest_phys_addr);
+ (slot->userspace_addr + addr - (slot->base_gfn<<PAGE_SHIFT));
s += size;
addr += size;
++ret;
}
- rcu_read_unlock();
return ret;
}
@@ -1104,7 +1084,7 @@ static unsigned next_desc(struct vring_desc *desc)
return next;
}
-static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
+static int get_indirect(struct kvm *kvm, struct vhost_virtqueue *vq,
struct iovec iov[], unsigned int iov_size,
unsigned int *out_num, unsigned int *in_num,
struct vhost_log *log, unsigned int *log_num,
@@ -1123,7 +1103,7 @@ static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EINVAL;
}
- ret = translate_desc(dev, indirect->addr, indirect->len, vq->indirect,
+ ret = translate_desc(kvm, indirect->addr, indirect->len, vq->indirect,
UIO_MAXIOV);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d in indirect.\n", ret);
@@ -1163,7 +1143,7 @@ static int get_indirect(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EINVAL;
}
- ret = translate_desc(dev, desc.addr, desc.len, iov + iov_count,
+ ret = translate_desc(kvm, desc.addr, desc.len, iov + iov_count,
iov_size - iov_count);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d indirect idx %d\n",
@@ -1209,6 +1189,13 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
unsigned int i, head, found = 0;
u16 last_avail_idx;
int ret;
+ struct kvm *kvm = get_kvm_from_task(current);
+
+ if(unlikely(kvm == NULL)){
+ vq_err(vq, "Failed to get corresponding kvm struct of vhost-%d\n",
+ current->pid);
+ return -EFAULT;
+ }
/* Check it isn't doing very strange things with descriptor numbers. */
last_avail_idx = vq->last_avail_idx;
@@ -1274,7 +1261,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
return -EFAULT;
}
if (desc.flags & VRING_DESC_F_INDIRECT) {
- ret = get_indirect(dev, vq, iov, iov_size,
+ ret = get_indirect(kvm, vq, iov, iov_size,
out_num, in_num,
log, log_num, &desc);
if (unlikely(ret < 0)) {
@@ -1285,7 +1272,7 @@ int vhost_get_vq_desc(struct vhost_dev *dev, struct vhost_virtqueue *vq,
continue;
}
- ret = translate_desc(dev, desc.addr, desc.len, iov + iov_count,
+ ret = translate_desc(kvm, desc.addr, desc.len, iov + iov_count,
iov_size - iov_count);
if (unlikely(ret < 0)) {
vq_err(vq, "Translation failure %d descriptor idx %d\n",
--
1.7.1
^ permalink raw reply related
* Re: [Qemu-devel] [RFC 0/4] virtio-mmio transport
From: Rusty Russell @ 2011-12-16 5:36 UTC (permalink / raw)
To: Paul Brook, Pawel Moll
Cc: Peter Maydell, virtualization, qemu-devel@nongnu.org,
Anthony Liguori, Paolo Bonzini
In-Reply-To: <201112121445.27873.paul@codesourcery.com>
On Mon, 12 Dec 2011 14:45:26 +0000, Paul Brook <paul@codesourcery.com> wrote:
> > I can do that, but not this year (on holiday from Friday 16th, without
> > any access to Internet whatsoever :-) One think to be decided is in what
> > order the halfs should be filled? Low first, then high? High then low?
> > Does it matter at all? :-)
>
> My inital though was that you shouldn't be changing this value when the ring
> is enabled. Unfortunately you disable the ring by setting the address to zero
> so that argument doesn't work :-/
It only does that after a reset, and since reset should set the values
to 0 (I don't think the spec says that, but it will for the new config)
we needn't do it at all.
It's just a convenient value for the driver to read and know the ring
has been cleaned up.
I think initialize by QueueNum makes sense.
Thanks,
Rusty.
^ permalink raw reply
* Re: [PATCH v3 2/3] hvc_init(): Enforce one-time initialization.
From: Amit Shah @ 2011-12-16 6:00 UTC (permalink / raw)
To: Miche Baker-Harvey
Cc: Stephen Rothwell, xen-devel, Konrad Rzeszutek Wilk,
Benjamin Herrenschmidt, linux-kernel, virtualization,
Anton Blanchard, Mike Waychison, ppc-dev, Greg Kroah-Hartman,
Eric Northrup
In-Reply-To: <CAB8Rdar=qOokxZkjQVRmo=zN_f75jPwzU+6=WBRo0g+P7w+pAw@mail.gmail.com>
On (Tue) 06 Dec 2011 [09:05:38], Miche Baker-Harvey wrote:
> Amit,
>
> Ah, indeed. I am not using MSI-X, so virtio_pci::vp_try_to_find_vqs()
> calls vp_request_intx() and sets up an interrupt callback. From
> there, when an interrupt occurs, the stack looks something like this:
>
> virtio_pci::vp_interrupt()
> virtio_pci::vp_vring_interrupt()
> virtio_ring::vring_interrupt()
> vq->vq.callback() <-- in this case, that's virtio_console::control_intr()
> workqueue::schedule_work()
> workqueue::queue_work()
> queue_work_on(get_cpu()) <-- queues the work on the current CPU.
>
> I'm not doing anything to keep multiple control message from being
> sent concurrently to the guest, and we will take those interrupts on
> any CPU. I've confirmed that the two instances of
> handle_control_message() are occurring on different CPUs.
Hi Miche,
Here's a quick-and-dirty hack that should help. I've not tested this,
and it's not yet signed-off-by. Let me know if this helps.
From 16708fa247c0dd34aa55d78166d65e463f9be6d6 Mon Sep 17 00:00:00 2001
Message-Id: <16708fa247c0dd34aa55d78166d65e463f9be6d6.1324015123.git.amit.shah@redhat.com>
From: Amit Shah <amit.shah@redhat.com>
Date: Fri, 16 Dec 2011 11:27:04 +0530
Subject: [PATCH 1/1] virtio: console: Serialise control work
We currently allow multiple instances of the control work handler to run
in parallel. This isn't expected to work; serialise access by disabling
interrupts on new packets from the Host and enable them when all the
existing ones are consumed.
---
drivers/char/virtio_console.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8e3c46d..72d396c 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1466,6 +1466,7 @@ static void control_work_handler(struct work_struct *work)
portdev = container_of(work, struct ports_device, control_work);
vq = portdev->c_ivq;
+ start:
spin_lock(&portdev->cvq_lock);
while ((buf = virtqueue_get_buf(vq, &len))) {
spin_unlock(&portdev->cvq_lock);
@@ -1483,6 +1484,10 @@ static void control_work_handler(struct work_struct *work)
}
}
spin_unlock(&portdev->cvq_lock);
+ if (unlikely(!virtqueue_enable_cb(vq))) {
+ virtqueue_disable_cb(vq);
+ goto start;
+ }
}
static void out_intr(struct virtqueue *vq)
@@ -1533,6 +1538,7 @@ static void control_intr(struct virtqueue *vq)
{
struct ports_device *portdev;
+ virtqueue_disable_cb(vq);
portdev = vq->vdev->priv;
schedule_work(&portdev->control_work);
}
--
1.7.7.4
Amit
^ permalink raw reply related
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Takuya Yoshikawa @ 2011-12-16 7:05 UTC (permalink / raw)
To: zanghongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang, levinsasha928
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
(2011/12/16 14:32), zanghongyong@huawei.com wrote:
> From: Hongyong Zang<zanghongyong@huawei.com>
>
> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> address relationship in its member *kvm_memslots*, these patches use kernel's
> kvm_memslots directly without the need of initialization and maintenance of
> vhost_memory.
Isn't vhost independent from KVM?
Takuya
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 7:05 UTC (permalink / raw)
To: zanghongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324013528-3663-1-git-send-email-zanghongyong@huawei.com>
On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
> From: Hongyong Zang <zanghongyong@huawei.com>
>
> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> address relationship in its member *kvm_memslots*, these patches use kernel's
> kvm_memslots directly without the need of initialization and maintenance of
> vhost_memory.
Conceptually, vhost isn't aware of KVM - it's just a driver which moves
data from vq to a tap device and back. You can't simply add KVM specific
code into vhost.
Whats the performance benefit?
--
Sasha.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Zang Hongyong @ 2011-12-16 7:40 UTC (permalink / raw)
To: Sasha Levin
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324019151.4496.9.camel@lappy>
于 2011/12/16,星期五 15:05, Sasha Levin 写道:
> On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
>> From: Hongyong Zang<zanghongyong@huawei.com>
>>
>> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
>> to translate GPA to HVA. Since kernel's kvm structure already maintains the
>> address relationship in its member *kvm_memslots*, these patches use kernel's
>> kvm_memslots directly without the need of initialization and maintenance of
>> vhost_memory.
> Conceptually, vhost isn't aware of KVM - it's just a driver which moves
> data from vq to a tap device and back. You can't simply add KVM specific
> code into vhost.
>
> Whats the performance benefit?
>
But vhost-net is only used in virtualization situation. vhost_memory is
maintained
by user space qemu.
In this way, the memory relationship can be accquired from kernel
without the
need of maintainence of vhost_memory from qemu.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 7:59 UTC (permalink / raw)
To: Zang Hongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <4EEAF5D1.2080805@huawei.com>
On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote:
> 于 2011/12/16,星期五 15:05, Sasha Levin 写道:
> > On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
> >> From: Hongyong Zang<zanghongyong@huawei.com>
> >>
> >> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
> >> to translate GPA to HVA. Since kernel's kvm structure already maintains the
> >> address relationship in its member *kvm_memslots*, these patches use kernel's
> >> kvm_memslots directly without the need of initialization and maintenance of
> >> vhost_memory.
> > Conceptually, vhost isn't aware of KVM - it's just a driver which moves
> > data from vq to a tap device and back. You can't simply add KVM specific
> > code into vhost.
> >
> > Whats the performance benefit?
> >
> But vhost-net is only used in virtualization situation. vhost_memory is
> maintained
> by user space qemu.
> In this way, the memory relationship can be accquired from kernel
> without the
> need of maintainence of vhost_memory from qemu.
You can't assume that vhost-* is used only along with qemu/kvm. Just as
virtio has more uses than just virtualization (heres one:
https://lkml.org/lkml/2011/10/25/139 ), there are more uses for vhost as
well.
There has been a great deal of effort to keep vhost and kvm untangled.
One example is the memory translation it has to do, another one is the
eventfd/irqfd thing it does just so it could signal an IRQ in the guest
instead of accessing the guest directly.
If you do see a great performance increase when tying vhost and KVM
together, it may be worth it to create some sort of an in-kernel
vhost-kvm bridging thing, but if the performance isn't noticeable we're
better off just leaving it as is and keeping the vhost code general.
--
Sasha.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Sasha Levin @ 2011-12-16 8:07 UTC (permalink / raw)
To: Zang Hongyong
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324022358.4496.25.camel@lappy>
On Fri, 2011-12-16 at 09:59 +0200, Sasha Levin wrote:
> There has been a great deal of effort to keep vhost and kvm untangled.
> One example is the memory translation it has to do, another one is the
> eventfd/irqfd thing it does just so it could signal an IRQ in the guest
> instead of accessing the guest directly.
Actually, CONFIG_VHOST_NET doesn't even depend on CONFIG_KVM, so your
patch will break build when (CONFIG_VHOST_NET=y && CONFIG_KVM=n).
--
Sasha.
^ permalink raw reply
* Re: [PATCH 0/2] vhot-net: Use kvm_memslots instead of vhost_memory to translate GPA to HVA
From: Zang Hongyong @ 2011-12-16 8:18 UTC (permalink / raw)
To: Sasha Levin
Cc: wusongwei, kvm, mst, netdev, hanweidong, linux-kernel,
virtualization, xiaowei.yang
In-Reply-To: <1324022358.4496.25.camel@lappy>
于 2011/12/16,星期五 15:59, Sasha Levin 写道:
> On Fri, 2011-12-16 at 15:40 +0800, Zang Hongyong wrote:
>> 于 2011/12/16,星期五 15:05, Sasha Levin 写道:
>>> On Fri, 2011-12-16 at 13:32 +0800, zanghongyong@huawei.com wrote:
>>>> From: Hongyong Zang<zanghongyong@huawei.com>
>>>>
>>>> Vhost-net uses its own vhost_memory, which results from user space (qemu) info,
>>>> to translate GPA to HVA. Since kernel's kvm structure already maintains the
>>>> address relationship in its member *kvm_memslots*, these patches use kernel's
>>>> kvm_memslots directly without the need of initialization and maintenance of
>>>> vhost_memory.
>>> Conceptually, vhost isn't aware of KVM - it's just a driver which moves
>>> data from vq to a tap device and back. You can't simply add KVM specific
>>> code into vhost.
>>>
>>> Whats the performance benefit?
>>>
>> But vhost-net is only used in virtualization situation. vhost_memory is
>> maintained
>> by user space qemu.
>> In this way, the memory relationship can be accquired from kernel
>> without the
>> need of maintainence of vhost_memory from qemu.
> You can't assume that vhost-* is used only along with qemu/kvm. Just as
> virtio has more uses than just virtualization (heres one:
> https://lkml.org/lkml/2011/10/25/139 ), there are more uses for vhost as
> well.
>
> There has been a great deal of effort to keep vhost and kvm untangled.
> One example is the memory translation it has to do, another one is the
> eventfd/irqfd thing it does just so it could signal an IRQ in the guest
> instead of accessing the guest directly.
>
> If you do see a great performance increase when tying vhost and KVM
> together, it may be worth it to create some sort of an in-kernel
> vhost-kvm bridging thing, but if the performance isn't noticeable we're
> better off just leaving it as is and keeping the vhost code general.
>
Thanks for your explanation.
Since memory layout is seldom changed after guest boots, the situation
manily occurs during initialization. There's no need for vhost-kvm
bridge now.
^ permalink raw reply
* CFP: Workshops at ACM HPDC 2012
From: Ioan Raicu @ 2011-12-16 22:53 UTC (permalink / raw)
To: virtualization
**** WORKSHOPS at ACM HPDC 2012 ****
http://www.hpdc.org/2012/workshops/
The ACM International Symposium on High-Performance Parallel and Distributed Computing (HPDC)
is the premier annual conference on the design, the implementation, the evaluation, and the
use of parallel and distributed systems for high-end computing. HPDC'12 will take place in
Delft, the Netherlands, a historical, picturesque city that is less than one hour away
from Amsterdam-Schiphol airport. The conference will be held on June 20-22 (Wednesday to
Friday), with affiliated workshops taking place on June 18-19 (Monday and Tuesday).
**** HPDC'12 WORKSHOPS CHAIR ****
Alexandru Iosup, Delft University of Technology, Delft, the Netherlands
The workshops include:
- Astro-HPC: Workshop on High-Performance Computing for Astronomy
http://www.pds.ewi.tudelft.nl/~varbanescu/AstroHPC/index.html
- ECMLS2012: 3rd Int'l Emerging Computational Methods for the Life Sciences Workshop
http://salsahpc.indiana.edu/ECMLS2012
- SocMP'12: First Workshop on Social Media Processing
http://www.pds.ewi.tudelft.nl/~iosup/socmp2012
- ScienceCloud: 3rd Workshop on Scientific Cloud Computing
http://ceng.usc.edu/~simmhan/ScienceCloud2012
- DIDC: Fifth Int'l Workshop on Data-Intensive Distributed Computing
http://www.cse.buffalo.edu/faculty/tkosar/didc2012
- ISDP: In-Situ Data Processing technologies
http://users.nccs.gov/~sklasky/isdp
- LSAP2012: 4th Workshop on Large-scale Systems and Applications Performance
http://www.lsap2012.org/
- MapReduce'12: The Third Int'l Workshop on MapReduce and its Applications
http://graal.ens-lyon.fr/mapreduce
- VTDC-2012: 6th Int'l Workshop on Virtualization Technologies in Distributed Computing
http://www.grid-appliance.org/wiki/index.php/VTDC12
--
=================================================================
Ioan Raicu, Ph.D.
Assistant Professor, Illinois Institute of Technology (IIT)
Guest Research Faculty, Argonne National Laboratory (ANL)
=================================================================
Data-Intensive Distributed Systems Laboratory, CS/IIT
Distributed Systems Laboratory, MCS/ANL
=================================================================
Cel: 1-847-722-0876
Office: 1-312-567-5704
Email: iraicu@cs.iit.edu
Web: http://www.cs.iit.edu/~iraicu/
Web: http://datasys.cs.iit.edu/
=================================================================
=================================================================
^ permalink raw reply
* Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
From: Michael S. Tsirkin @ 2011-12-18 10:18 UTC (permalink / raw)
To: Rusty Russell; +Cc: Sasha Levin, virtualization
In-Reply-To: <87zketp9nz.fsf@rustcorp.com.au>
On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
> On Thu, 15 Dec 2011 10:27:50 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Tue, Dec 13, 2011 at 12:51:20PM +1030, Rusty Russell wrote:
> > I mean like this in block:
> >
> >
> >
> > /* Host must always specify the capacity. */
> > vdev->config->get(vdev, offsetof(struct virtio_blk_config,
> > capacity),
> > &capacity, sizeof(capacity));
> >
> > /* If capacity is too big, truncate with warning. */
> > if ((sector_t)capacity != capacity) {
> > dev_warn(&vdev->dev, "Capacity %llu too large:
> > truncating\n",
> > (unsigned long long)capacity);
> > capacity = (sector_t)-1;
> > }
> >
> >
> > Now let's assume capacity field is changed from 0x8000 to 0x10000
> > on host. Is it possible that we read two upper bytes
> > before the change so we see 0x0000....
> > and 2 lower bytes after the change
> > so we see 0x....0000 and resulting capacity appears
> > to be 0?
> >
> > If no why not?
>
> Same issue in reverse with the guest setting the MAC address in
> virtio_net, if the host were reading it. And virtio_balloon? We have
> ignored it, so far.
>
> Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
> appears and vanishes around config writes by either side? Kind of a
> hack though...
>
> Cheers,
> Rusty.
Not sure how this can work in such a setup: when would guest
check this bit to avoid races?
A separate registers also seems nicer than a flag.
Some other possible design choices:
- a flag to signal config accesses in progress by guest
host would need to buffer changes and apply them in one go
when flag is cleared
- a register to make host get/set config in guest memory
- use a control vq for all devices
The last two involve defining a structure specifying
offset and length of device configuration affected.
The last option is preferable if other transports
besides pci might have the same issue: we solve
it once and for all this way.
--
MST
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Amos Kong @ 2011-12-19 2:19 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, Benjamin Herrenschmidt, linux-kernel,
virtualization, rhod, linux-arm-kernel
In-Reply-To: <87wra2tlue.fsf@rustcorp.com.au>
On 12/12/11 13:12, Rusty Russell wrote:
> On Mon, 12 Dec 2011 11:06:53 +0800, Amos Kong<akong@redhat.com> wrote:
>> On 12/12/11 06:27, Benjamin Herrenschmidt wrote:
>>> On Sun, 2011-12-11 at 14:25 +0200, Michael S. Tsirkin wrote:
>>>
>>>> Forwarding some results by Amos, who run multiple netperf streams in
>>>> parallel, from an external box to the guest. TCP_STREAM results were
>>>> noisy. This could be due to buffering done by TCP, where packet size
>>>> varies even as message size is constant.
>>>>
>>>> TCP_RR results were consistent. In this benchmark, after switching
>>>> to mandatory barriers, CPU utilization increased by up to 35% while
>>>> throughput went down by up to 14%. the normalized throughput/cpu
>>>> regressed consistently, between 7 and 35%
>>>>
>>>> The "fix" applied was simply this:
>>>
>>> What machine& processor was this ?
>>
>> pined guest memory to numa node 1
>
> Please try this patch. How much does the branch cost us?
>
> (Compiles, untested).
>
> Thanks,
> Rusty.
>
> From: Rusty Russell<rusty@rustcorp.com.au>
> Subject: virtio: harsher barriers for virtio-mmio.
>
> We were cheating with our barriers; using the smp ones rather than the
> real device ones. That was fine, until virtio-mmio came along, which
> could be talking to a real device (a non-SMP CPU).
>
> Unfortunately, just putting back the real barriers (reverting
> d57ed95d) causes a performance regression on virtio-pci. In
> particular, Amos reports netbench's TCP_RR over virtio_net CPU
> utilization increased up to 35% while throughput went down by up to
> 14%.
>
> By comparison, this branch costs us???
>
> Reference: https://lkml.org/lkml/2011/12/11/22
>
> Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
> ---
> drivers/lguest/lguest_device.c | 10 ++++++----
> drivers/s390/kvm/kvm_virtio.c | 2 +-
> drivers/virtio/virtio_mmio.c | 7 ++++---
> drivers/virtio/virtio_pci.c | 4 ++--
> drivers/virtio/virtio_ring.c | 34 +++++++++++++++++++++-------------
> include/linux/virtio_ring.h | 1 +
> tools/virtio/linux/virtio.h | 1 +
> tools/virtio/virtio_test.c | 3 ++-
> 8 files changed, 38 insertions(+), 24 deletions(-)
Hi all,
I tested with the same environment and scenarios.
tested one scenarios for three times and compute the average for more
precision.
Thanks, Amos
--------- compare results -----------
Mon Dec 19 09:51:09 2011
1 - avg-old.netperf.exhost_guest.txt
2 - avg-fixed.netperf.exhost_guest.txt
======
TCP_STREAM
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 1073.54| 10.50| 102| 0| 31|
0| 1612| 0| 16| 487641| 489753|
504764| 0.00| 0.00
2 1| 64| 1079.44| 10.29| 104| 0| 30|
0| 1594| 0| 17| 487156| 488828|
504411| 0.00| 0.00
% | 0.0| +0.5| -2.0| +2.0| 0| -3.2|
0| -1.1| 0| +6.2| -0.1| -0.2|
-0.1| 0| 0
1 2| 64| 2141.12| 15.72| 136| 0| 33|
0| 1744| 0| 34| 873777| 972303|
928926| 0.00| 0.00
2 2| 64| 2140.88| 15.64| 137| 0| 33|
0| 1744| 0| 34| 926588| 942841|
974095| 0.00| 0.00
% | 0.0| -0.0| -0.5| +0.7| 0| 0.0|
0| 0.0| 0| 0.0| +6.0| -3.0|
+4.9| 0| 0
1 4| 64| 4076.80| 19.82| 205| 0| 30|
0| 1577| 0| 67| 1422282| 1166425|
1539219| 0.00| 0.00
2 4| 64| 4094.32| 20.70| 197| 0| 31|
0| 1612| 0| 68| 1704330| 1314077|
1833394| 0.00| 0.00
% | 0.0| +0.4| +4.4| -3.9| 0| +3.3|
0| +2.2| 0| +1.5| +19.8| +12.7|
+19.1| 0| 0
1 1| 256| 2867.48| 13.44| 213| 0| 32|
0| 1726| 0| 14| 666430| 694922|
690730| 0.00| 0.00
2 1| 256| 2874.20| 12.71| 226| 0| 32|
0| 1709| 0| 14| 697960| 740407|
721807| 0.00| 0.00
% | 0.0| +0.2| -5.4| +6.1| 0| 0.0|
0| -1.0| 0| 0.0| +4.7| +6.5|
+4.5| 0| 0
1 2| 256| 5642.82| 17.61| 320| 0| 30|
0| 1594| 0| 30| 1226861| 1236081|
1268562| 0.00| 0.00
2 2| 256| 5661.06| 17.41| 326| 0| 30|
0| 1594| 0| 29| 1175696| 1143490|
1221528| 0.00| 0.00
% | 0.0| +0.3| -1.1| +1.9| 0| 0.0|
0| 0.0| 0| -3.3| -4.2| -7.5|
-3.7| 0| 0
1 4| 256| 9404.27| 23.55| 399| 0| 33|
0| 1744| 0| 37| 1692245| 659975|
1765103| 0.00| 0.00
2 4| 256| 8761.11| 23.18| 376| 0| 32|
0| 1726| 0| 36| 1699382| 418992|
1870804| 0.00| 0.00
% | 0.0| -6.8| -1.6| -5.8| 0| -3.0|
0| -1.0| 0| -2.7| +0.4| -36.5|
+6.0| 0| 0
1 1| 512| 3803.66| 14.20| 267| 0| 30|
0| 1594| 0| 14| 693992| 750078|
721107| 0.00| 0.00
2 1| 512| 3838.02| 15.47| 248| 0| 31|
0| 1612| 0| 15| 811709| 773505|
838788| 0.00| 0.00
% | 0.0| +0.9| +8.9| -7.1| 0| +3.3|
0| +1.1| 0| +7.1| +17.0| +3.1|
+16.3| 0| 0
1 2| 512| 8606.11| 19.34| 444| 0| 32|
0| 1709| 0| 29| 1264624| 647652|
1309740| 0.00| 0.00
2 2| 512| 8127.80| 18.93| 428| 0| 32|
0| 1726| 0| 28| 1216606| 1179269|
1266260| 0.00| 0.00
% | 0.0| -5.6| -2.1| -3.6| 0| 0.0|
0| +1.0| 0| -3.4| -3.8| +82.1|
-3.3| 0| 0
1 4| 512| 9409.41| 22.88| 413| 0| 30|
0| 1577| 0| 35| 1592587| 1072862|
1746787| 0.00| 0.00
2 4| 512| 9217.34| 23.05| 400| 0| 30|
0| 1594| 0| 34| 1596515| 513742|
1831538| 0.00| 0.00
% | 0.0| -2.0| +0.7| -3.1| 0| 0.0|
0| +1.1| 0| -2.9| +0.2| -52.1|
+4.9| 0| 0
1 1| 1024| 4389.75| 14.62| 303| 0| 32|
0| 1726| 0| 14| 663417| 611555|
689028| 0.00| 0.00
2 1| 1024| 4390.44| 13.66| 321| 0| 32|
0| 1726| 0| 13| 609836| 556090|
634511| 0.00| 0.00
% | 0.0| +0.0| -6.6| +5.9| 0| 0.0|
0| 0.0| 0| -7.1| -8.1| -9.1|
-7.9| 0| 0
1 2| 1024| 9046.18| 19.63| 460| 0| 30|
0| 1594| 0| 28| 1206853| 1054653|
1256203| 0.00| 0.00
2 2| 1024| 9027.54| 20.15| 447| 0| 30|
0| 1577| 0| 27| 1179555| 884408|
1226843| 0.00| 0.00
% | 0.0| -0.2| +2.6| -2.8| 0| 0.0|
0| -1.1| 0| -3.6| -2.3| -16.1|
-2.3| 0| 0
1 4| 1024| 9410.41| 22.01| 427| 0| 32|
0| 1726| 0| 36| 1734433| 887190|
1852486| 0.00| 0.00
2 4| 1024| 9409.11| 23.18| 405| 0| 32|
0| 1726| 0| 34| 1695359| 625268|
1803599| 0.00| 0.00
% | 0.0| -0.0| +5.3| -5.2| 0| 0.0|
0| 0.0| 0| -5.6| -2.3| -29.5|
-2.6| 0| 0
TCP_MAERTS
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 1056.13| 17.51| 59| 0| 30|
0| 1594| 3| 86| 476098| 4780186|
538158| 0.00| 0.00
2 1| 64| 1065.51| 17.64| 60| 0| 30|
0| 1594| 3| 87| 476836| 4823602|
538860| 0.00| 0.00
% | 0.0| +0.9| +0.7| +1.7| 0| 0.0|
0| 0.0| 0.0| +1.2| +0.2| +0.9|
+0.1| 0| 0
1 2| 64| 2472.80| 32.18| 76| 0| 32|
0| 1709| 2| 199| 479119| 2089931|
600119| 0.00| 0.00
2 2| 64| 2468.76| 32.28| 76| 0| 33|
0| 1744| 1| 199| 479372| 2179342|
600328| 0.00| 0.00
% | 0.0| -0.2| +0.3| 0.0| 0| +3.1|
0| +2.0| -50.0| 0.0| +0.1| +4.3|
+0.0| 0| 0
1 4| 64| 2453.22| 32.20| 75| 0| 31|
0| 1612| 2| 198| 479223| 2175801|
600081| 0.00| 0.00
2 4| 64| 2465.68| 32.30| 76| 0| 30|
0| 1594| 3| 200| 479404| 2108293|
600252| 0.00| 0.00
% | 0.0| +0.5| +0.3| +1.3| 0| -3.2|
0| -1.1| +50.0| +1.0| +0.0| -3.1|
+0.0| 0| 0
1 1| 256| 3608.37| 24.59| 146| 0| 32|
0| 1726| 2| 277| 88346| 108310|
150637| 0.00| 0.00
2 1| 256| 3611.12| 24.95| 144| 0| 32|
0| 1709| 0| 281| 83319| 64354|
145511| 0.00| 0.00
% | 0.0| +0.1| +1.5| -1.4| 0| 0.0|
0| -1.0| -100.0| +1.4| -5.7| -40.6|
-3.4| 0| 0
1 2| 256| 7373.32| 26.83| 274| 0| 31|
0| 1612| 0| 4185| 278932| 264031|
377267| 0.00| 0.00
2 2| 256| 7460.03| 26.93| 276| 0| 30|
0| 1594| 1| 5913| 270840| 246165|
371999| 0.00| 0.00
% | 0.0| +1.2| +0.4| +0.7| 0| -3.2|
0| -1.1| 0| +41.3| -2.9| -6.8|
-1.4| 0| 0
1 4| 256| 9322.66| 29.73| 313| 0| 32|
0| 1709| 848| 3041| 363114| 329308|
482586| 0.00| 0.00
2 4| 256| 9365.52| 29.59| 316| 0| 33|
0| 1744| 414| 2884| 371485| 339191|
491366| 0.00| 0.00
% | 0.0| +0.5| -0.5| +1.0| 0| +3.1|
0| +2.0| -51.2| -5.2| +2.3| +3.0|
+1.8| 0| 0
1 1| 512| 9360.25| 17.20| 543| 0| 30|
0| 1577| 0| 387| 438621| 408062|
499989| 0.00| 0.00
2 1| 512| 8899.37| 18.17| 495| 0| 30|
0| 1594| 0| 5049| 393341| 371545|
459397| 0.00| 0.00
% | 0.0| -4.9| +5.6| -8.8| 0| 0.0|
0| +1.1| 0| +1204.7| -10.3| -8.9|
-8.1| 0| 0
1 2| 512| 8713.11| 20.77| 420| 0| 32|
0| 1726| 0| 11227| 296157| 246495|
371632| 0.00| 0.00
2 2| 512| 8686.31| 20.72| 421| 0| 32|
0| 1709| 0| 11002| 296608| 246597|
371797| 0.00| 0.00
% | 0.0| -0.3| -0.2| +0.2| 0| 0.0|
0| -1.0| 0| -2.0| +0.2| +0.0|
+0.0| 0| 0
1 4| 512| 8780.40| 22.72| 386| 0| 30|
0| 1594| 0| 10337| 303619| 249822|
385457| 0.00| 0.00
2 4| 512| 8858.51| 22.66| 390| 0| 30|
0| 1577| 0| 9968| 301847| 246543|
382121| 0.00| 0.00
% | 0.0| +0.9| -0.3| +1.0| 0| 0.0|
0| -1.1| 0| -3.6| -0.6| -1.3|
-0.9| 0| 0
1 1| 1024| 9387.09| 16.43| 571| 0| 32|
0| 1726| 0| 84| 452351| 429483|
504022| 0.00| 0.00
2 1| 1024| 9388.90| 16.51| 568| 0| 32|
0| 1726| 2| 76| 446994| 422489|
499025| 0.00| 0.00
% | 0.0| +0.0| +0.5| -0.5| 0| 0.0|
0| 0.0| 0| -9.5| -1.2| -1.6|
-1.0| 0| 0
1 2| 1024| 9361.43| 17.26| 542| 0| 30|
0| 1594| 5| 647| 388626| 358303|
442125| 0.00| 0.00
2 2| 1024| 9364.78| 17.25| 542| 0| 31|
0| 1612| 35| 554| 389326| 360169|
442343| 0.00| 0.00
% | 0.0| +0.0| -0.1| 0.0| 0| +3.3|
0| +1.1| +600.0| -14.4| +0.2| +0.5|
+0.0| 0| 0
1 4| 1024| 9381.57| 18.35| 510| 0| 32|
0| 1726| 1189| 648| 405900| 376269|
459845| 0.00| 0.00
2 4| 1024| 9393.48| 18.27| 513| 0| 32|
0| 1726| 1754| 610| 402132| 373768|
455629| 0.00| 0.00
% | 0.0| +0.1| -0.4| +0.6| 0| 0.0|
0| 0.0| +47.5| -5.9| -0.9| -0.7|
-0.9| 0| 0
TCP_RR
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 50| 64| 10903.70| 8.03| 1382| 0| 32|
0| 1698| 0| 9| 654298| 654362|
665532| 0.00| 0.00
2 50| 64| 10880.50| 7.40| 1488| 0| 32|
0| 1698| 0| 10| 652907| 652973|
667042| 0.00| 0.00
% | 0.0| -0.2| -7.8| +7.7| 0| 0.0|
0| 0.0| 0| +11.1| -0.2| -0.2|
+0.2| 0| 0
1 100| 64| 10953.00| 8.40| 1332| 0| 34|
0| 1830| 0| 10| 657257| 657325|
667088| 0.00| 0.00
2 100| 64| 10882.78| 7.67| 1439| 0| 34|
0| 1830| 0| 9| 653044| 653110|
668883| 0.00| 0.00
% | 0.0| -0.6| -8.7| +8.0| 0| 0.0|
0| 0.0| 0| -10.0| -0.6| -0.6|
+0.3| 0| 0
1 250| 64| 10902.66| 8.57| 1300| 0| 33|
0| 1716| 0| 10| 654235| 654308|
665518| 0.00| 0.00
2 250| 64| 10866.79| 7.58| 1449| 0| 32|
0| 1664| 0| 10| 652083| 652155|
666869| 0.00| 0.00
% | 0.0| -0.3| -11.6| +11.5| 0| -3.0|
0| -3.0| 0| 0.0| -0.3| -0.3|
+0.2| 0| 0
1 500| 64| 10924.34| 7.25| 1509| 0| 34|
0| 1830| 0| 10| 655536| 655619|
665776| 0.00| 0.00
2 500| 64| 10927.52| 6.50| 1684| 0| 34|
0| 1813| 0| 10| 655726| 655803|
668527| 0.00| 0.00
% | 0.0| +0.0| -10.3| +11.6| 0| 0.0|
0| -0.9| 0| 0.0| +0.0| +0.0|
+0.4| 0| 0
1 50| 256| 10407.35| 9.38| 1112| 0| 32|
0| 1681| 0| 9| 624516| 624581|
639159| 0.00| 0.00
2 50| 256| 10422.60| 9.45| 1108| 0| 33|
0| 1716| 0| 9| 625432| 625498|
641343| 0.00| 0.00
% | 0.0| +0.1| +0.7| -0.4| 0| +3.1|
0| +2.1| 0| 0.0| +0.1| +0.1|
+0.3| 0| 0
1 100| 256| 10404.30| 8.99| 1159| 0| 34|
0| 1830| 0| 9| 624335| 624400|
637357| 0.00| 0.00
2 100| 256| 10442.84| 9.57| 1093| 0| 35|
0| 1848| 0| 9| 626650| 626714|
639017| 0.00| 0.00
% | 0.0| +0.4| +6.5| -5.7| 0| +2.9|
0| +1.0| 0| 0.0| +0.4| +0.4|
+0.3| 0| 0
1 250| 256| 10427.71| 9.10| 1157| 0| 32|
0| 1698| 0| 9| 625738| 625822|
641221| 0.00| 0.00
2 250| 256| 10464.71| 9.69| 1085| 0| 32|
0| 1698| 0| 9| 627960| 628040|
640680| 0.00| 0.00
% | 0.0| +0.4| +6.5| -6.2| 0| 0.0|
0| 0.0| 0| 0.0| +0.4| +0.4|
-0.1| 0| 0
1 500| 256| 10442.18| 8.65| 1217| 0| 34|
0| 1830| 0| 10| 626608| 626675|
640081| 0.00| 0.00
2 500| 256| 10463.74| 9.63| 1089| 0| 34|
0| 1813| 0| 9| 627904| 627967|
643152| 0.00| 0.00
% | 0.0| +0.2| +11.3| -10.5| 0| 0.0|
0| -0.9| 0| -10.0| +0.2| +0.2|
+0.5| 0| 0
1 50| 512| 8505.70| 7.20| 1191| 0| 33|
0| 1716| 0| 7| 510418| 510486|
524904| 0.00| 0.00
2 50| 512| 8563.34| 7.24| 1185| 0| 32|
0| 1664| 0| 8| 513877| 513940|
526294| 0.00| 0.00
% | 0.0| +0.7| +0.6| -0.5| 0| -3.0|
0| -3.0| 0| +14.3| +0.7| +0.7|
+0.3| 0| 0
1 100| 512| 8509.97| 7.00| 1226| 0| 34|
0| 1830| 0| 7| 510674| 510756|
525205| 0.00| 0.00
2 100| 512| 8555.22| 7.52| 1144| 0| 34|
0| 1830| 0| 7| 513389| 513471|
526609| 0.00| 0.00
% | 0.0| +0.5| +7.4| -6.7| 0| 0.0|
0| 0.0| 0| 0.0| +0.5| +0.5|
+0.3| 0| 0
1 250| 512| 8507.35| 7.21| 1183| 0| 32|
0| 1681| 0| 7| 510518| 510579|
524294| 0.00| 0.00
2 250| 512| 8578.13| 7.01| 1223| 0| 33|
0| 1716| 0| 8| 514765| 514829|
526481| 0.00| 0.00
% | 0.0| +0.8| -2.8| +3.4| 0| +3.1|
0| +2.1| 0| +14.3| +0.8| +0.8|
+0.4| 0| 0
1 500| 512| 8521.68| 6.54| 1302| 0| 34|
0| 1813| 0| 8| 511375| 511443|
523357| 0.00| 0.00
2 500| 512| 8573.17| 6.94| 1235| 0| 34|
0| 1830| 0| 7| 514467| 514533|
526131| 0.00| 0.00
% | 0.0| +0.6| +6.1| -5.1| 0| 0.0|
0| +0.9| 0| -12.5| +0.6| +0.6|
+0.5| 0| 0
1 50| 1024| 8150.01| 7.69| 1060| 0| 32|
0| 1681| 0| 7| 489075| 489155|
503136| 0.00| 0.00
2 50| 1024| 8129.35| 7.65| 1062| 0| 34|
0| 1804| 0| 7| 487841| 487915|
502061| 0.00| 0.00
% | 0.0| -0.3| -0.5| +0.2| 0| +6.2|
0| +7.3| 0| 0.0| -0.3| -0.3|
-0.2| 0| 0
1 100| 1024| 8166.06| 7.53| 1083| 0| 34|
0| 1804| 0| 7| 490039| 490104|
502990| 0.00| 0.00
2 100| 1024| 8118.23| 7.77| 1044| 0| 33|
0| 1725| 0| 7| 487171| 487236|
501939| 0.00| 0.00
% | 0.0| -0.6| +3.2| -3.6| 0| -2.9|
0| -4.4| 0| 0.0| -0.6| -0.6|
-0.2| 0| 0
1 250| 1024| 8175.35| 7.58| 1079| 0| 35|
0| 1848| 0| 7| 490597| 490657|
503641| 0.00| 0.00
2 250| 1024| 8146.63| 7.59| 1072| 0| 34|
0| 1813| 0| 7| 488874| 488939|
502010| 0.00| 0.00
% | 0.0| -0.4| +0.1| -0.6| 0| -2.9|
0| -1.9| 0| 0.0| -0.4| -0.4|
-0.3| 0| 0
1 500| 1024| 8182.51| 7.61| 1075| 0| 32|
0| 1698| 0| 7| 491028| 491095|
504222| 0.00| 0.00
2 500| 1024| 8157.39| 7.58| 1075| 0| 33|
0| 1716| 0| 7| 489521| 489593|
502368| 0.00| 0.00
% | 0.0| -0.3| -0.4| 0.0| 0| +3.1|
0| +1.1| 0| 0.0| -0.3| -0.3|
-0.4| 0| 0
Mon Dec 19 09:51:09 2011
1 - avg-old.netperf.host_guest.txt
2 - avg-fixed.netperf.host_guest.txt
======
TCP_STREAM
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 715.76| 28.44| 24| 0| 31|
0| 1629| 0| 36| 3206862| 1733540|
3245171| 0.00| 0.00
2 1| 64| 714.82| 28.44| 25| 0| 31|
0| 1612| 0| 36| 3204256| 1709508|
3242450| 0.00| 0.00
% | 0.0| -0.1| 0.0| +4.2| 0| 0.0|
0| -1.0| 0| 0.0| -0.1| -1.4|
-0.1| 0| 0
1 2| 64| 1449.31| 41.23| 35| 0| 33|
0| 1744| 0| 66| 2764635| 1667527|
2815591| 0.00| 0.00
2 2| 64| 1442.92| 41.32| 34| 0| 32|
0| 1709| 0| 66| 2751461| 1659498|
2799277| 0.00| 0.00
% | 0.0| -0.4| +0.2| -2.9| 0| -3.0|
0| -2.0| 0| 0.0| -0.5| -0.5|
-0.6| 0| 0
1 4| 64| 2671.25| 48.95| 54| 0| 30|
0| 1577| 0| 47| 914085| 289771|
947054| 0.00| 0.00
2 4| 64| 2652.68| 48.20| 54| 0| 30|
0| 1594| 0| 46| 882300| 293273|
914249| 0.00| 0.00
% | 0.0| -0.7| -1.5| 0.0| 0| 0.0|
0| +1.1| 0| -2.1| -3.5| +1.2|
-3.5| 0| 0
1 1| 256| 1478.61| 29.34| 50| 0| 32|
0| 1709| 0| 64| 3502384| 1541681|
3545371| 0.00| 0.00
2 1| 256| 1481.38| 29.27| 50| 0| 32|
0| 1726| 0| 64| 3485623| 1526105|
3528343| 0.00| 0.00
% | 0.0| +0.2| -0.2| 0.0| 0| 0.0|
0| +1.0| 0| 0.0| -0.5| -1.0|
-0.5| 0| 0
1 2| 256| 3095.93| 42.31| 72| 0| 31|
0| 1612| 0| 123| 1521019| 466426|
1637722| 0.00| 0.00
2 2| 256| 3098.16| 42.03| 73| 0| 30|
0| 1594| 0| 123| 1519458| 472632|
1632462| 0.00| 0.00
% | 0.0| +0.1| -0.7| +1.4| 0| -3.2|
0| -1.1| 0| 0.0| -0.1| +1.3|
-0.3| 0| 0
1 4| 256| 6553.60| 38.44| 170| 0| 33|
0| 1761| 0| 38| 1343193| 237604|
1402385| 0.00| 0.00
2 4| 256| 6649.37| 38.34| 172| 0| 32|
0| 1726| 0| 32| 1343770| 236320|
1400875| 0.00| 0.00
% | 0.0| +1.5| -0.3| +1.2| 0| -3.0|
0| -2.0| 0| -15.8| +0.0| -0.5|
-0.1| 0| 0
1 1| 512| 1818.40| 29.28| 61| 0| 31|
0| 1646| 0| 76| 3326887| 1491961|
3371189| 0.00| 0.00
2 1| 512| 1822.74| 29.45| 61| 0| 30|
0| 1577| 0| 76| 3309934| 1470715|
3352921| 0.00| 0.00
% | 0.0| +0.2| +0.6| 0.0| 0| -3.2|
0| -4.2| 0| 0.0| -0.5| -1.4|
-0.5| 0| 0
1 2| 512| 3931.72| 43.51| 89| 0| 33|
0| 1761| 0| 137| 1148331| 301194|
1270351| 0.00| 0.00
2 2| 512| 3926.16| 43.45| 90| 0| 32|
0| 1726| 0| 135| 1166280| 306110|
1288869| 0.00| 0.00
% | 0.0| -0.1| -0.1| +1.1| 0| -3.0|
0| -2.0| 0| -1.5| +1.6| +1.6|
+1.5| 0| 0
1 4| 512| 8634.49| 40.69| 211| 0| 31|
0| 1612| 0| 53| 1869998| 353856|
1948593| 0.00| 0.00
2 4| 512| 9137.12| 40.77| 223| 0| 30|
0| 1594| 0| 48| 1879574| 362851|
1959044| 0.00| 0.00
% | 0.0| +5.8| +0.2| +5.7| 0| -3.2|
0| -1.1| 0| -9.4| +0.5| +2.5|
+0.5| 0| 0
1 1| 1024| 2042.67| 29.50| 68| 0| 33|
0| 1778| 0| 84| 3087032| 1309160|
3130736| 0.00| 0.00
2 1| 1024| 2033.24| 29.51| 68| 0| 32|
0| 1726| 0| 83| 3082898| 1295936|
3125229| 0.00| 0.00
% | 0.0| -0.5| +0.0| 0.0| 0| -3.0|
0| -2.9| 0| -1.2| -0.1| -1.0|
-0.2| 0| 0
1 2| 1024| 7703.26| 39.58| 194| 0| 32|
0| 1673| 0| 65| 2522172| 663302|
2684835| 0.00| 0.00
2 2| 1024| 7657.00| 39.27| 194| 0| 30|
0| 1594| 0| 62| 2607281| 698035|
2755198| 0.00| 0.00
% | 0.0| -0.6| -0.8| 0.0| 0| -6.2|
0| -4.7| 0| -4.6| +3.4| +5.2|
+2.6| 0| 0
1 4| 1024| 11814.84| 39.38| 299| 0| 32|
0| 1700| 0| 28| 2510318| 576071|
2596631| 0.00| 0.00
2 4| 1024| 12871.76| 38.93| 330| 0| 32|
0| 1726| 0| 25| 2232437| 632785|
2316035| 0.00| 0.00
% | 0.0| +8.9| -1.1| +10.4| 0| 0.0|
0| +1.5| 0| -10.7| -11.1| +9.8|
-10.8| 0| 0
TCP_MAERTS
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 706.98| 26.25| 26| 0| 31|
0| 1656| 0| 80| 2630204| 4185330|
2692397| 0.00| 0.00
2 1| 64| 767.45| 27.78| 27| 0| 30|
0| 1594| 0| 85| 2626694| 4317273|
2688799| 0.00| 0.00
% | 0.0| +8.6| +5.8| +3.8| 0| -3.2|
0| -3.7| 0| +6.2| -0.1| +3.2|
-0.1| 0| 0
1 2| 64| 2644.57| 42.60| 61| 0| 32|
0| 1700| 0| 34863| 49057| 16791|
204805| 0.00| 0.00
2 2| 64| 2721.19| 42.69| 63| 0| 32|
0| 1709| 0| 42365| 52739| 20094|
215895| 0.00| 0.00
% | 0.0| +2.9| +0.2| +3.3| 0| 0.0|
0| +0.5| 0| +21.5| +7.5| +19.7|
+5.4| 0| 0
1 4| 64| 2756.40| 42.69| 64| 0| 32|
0| 1708| 0| 52043| 47976| 12694|
220732| 0.00| 0.00
2 4| 64| 2709.19| 42.79| 62| 0| 30|
0| 1594| 0| 50144| 47275| 12743|
218074| 0.00| 0.00
% | 0.0| -1.7| +0.2| -3.1| 0| -6.2|
0| -6.7| 0| -3.6| -1.5| +0.4|
-1.2| 0| 0
1 1| 256| 3785.63| 32.34| 116| 0| 33|
0| 1734| 0| 36642| 58940| 1187|
157652| 0.00| 0.00
2 1| 256| 3593.17| 32.90| 108| 0| 32|
0| 1726| 0| 33179| 54980| 1130|
150168| 0.00| 0.00
% | 0.0| -5.1| +1.7| -6.9| 0| -3.0|
0| -0.5| 0| -9.5| -6.7| -4.8|
-4.7| 0| 0
1 2| 256| 8316.26| 40.45| 205| 0| 32|
0| 1673| 0| 28302| 114835| 1655|
251137| 0.00| 0.00
2 2| 256| 8390.41| 41.17| 203| 0| 30|
0| 1594| 0| 31222| 115372| 1696|
257151| 0.00| 0.00
% | 0.0| +0.9| +1.8| -1.0| 0| -6.2|
0| -4.7| 0| +10.3| +0.5| +2.5|
+2.4| 0| 0
1 4| 256| 9672.49| 42.40| 227| 0| 33|
0| 1761| 0| 30045| 132027| 3059|
283491| 0.00| 0.00
2 4| 256| 9741.71| 42.57| 228| 0| 32|
0| 1726| 6| 28875| 132125| 1999|
283036| 0.00| 0.00
% | 0.0| +0.7| +0.4| +0.4| 0| -3.0|
0| -2.0| 0| -3.9| +0.1| -34.7|
-0.2| 0| 0
1 1| 512| 6052.41| 32.23| 187| 0| 31|
0| 1612| 0| 44681| 86084| 2592|
187465| 0.00| 0.00
2 1| 512| 6267.37| 32.51| 192| 0| 30|
0| 1577| 0| 45278| 88449| 2708|
191374| 0.00| 0.00
% | 0.0| +3.6| +0.9| +2.7| 0| -3.2|
0| -2.2| 0| +1.3| +2.7| +4.5|
+2.1| 0| 0
1 2| 512| 12714.52| 38.27| 331| 0| 33|
0| 1744| 0| 24843| 169170| 2381|
292210| 0.00| 0.00
2 2| 512| 11341.65| 37.30| 303| 0| 32|
0| 1726| 14| 27393| 152465| 2980|
270740| 0.00| 0.00
% | 0.0| -10.8| -2.5| -8.5| 0| -3.0|
0| -1.0| 0| +10.3| -9.9| +25.2|
-7.3| 0| 0
1 4| 512| 16127.03| 40.80| 394| 0| 31|
0| 1612| 0| 15063| 210628| 2234|
344124| 0.00| 0.00
2 4| 512| 14709.72| 39.94| 367| 0| 31|
0| 1612| 0| 17823| 193670| 4457|
324744| 0.00| 0.00
% | 0.0| -8.8| -2.1| -6.9| 0| 0.0|
0| 0.0| 0| +18.3| -8.1| +99.5|
-5.6| 0| 0
1 1| 1024| 6436.88| 30.31| 212| 0| 33|
0| 1778| 0| 47820| 83940| 2007|
172847| 0.00| 0.00
2 1| 1024| 6495.48| 30.51| 212| 0| 32|
0| 1726| 0| 47771| 85436| 2038|
175027| 0.00| 0.00
% | 0.0| +0.9| +0.7| 0.0| 0| -3.0|
0| -2.9| 0| -0.1| +1.8| +1.5|
+1.3| 0| 0
1 2| 1024| 12245.34| 33.44| 365| 0| 31|
0| 1629| 0| 26499| 162142| 2909|
255717| 0.00| 0.00
2 2| 1024| 12913.57| 33.93| 380| 0| 31|
0| 1612| 0| 24196| 171386| 3671|
266270| 0.00| 0.00
% | 0.0| +5.5| +1.5| +4.1| 0| 0.0|
0| -1.0| 0| -8.7| +5.7| +26.2|
+4.1| 0| 0
1 4| 1024| 16428.48| 34.81| 471| 0| 32|
0| 1709| 0| 12496| 215031| 6557|
318039| 0.00| 0.00
2 4| 1024| 17294.33| 35.05| 492| 0| 32|
0| 1709| 0| 9444| 224694| 4095|
328098| 0.00| 0.00
% | 0.0| +5.3| +0.7| +4.5| 0| 0.0|
0| 0.0| 0| -24.4| +4.5| -37.5|
+3.2| 0| 0
TCP_RR
sessions| size|throughput| cpu| normalize| #tx-pkts|
#rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
#io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 50| 64| 14626.43| 14.93| 980| 0| 32|
0| 1681| 0| 13| 877664| 877731|
902624| 0.00| 0.00
2 50| 64| 14639.95| 13.10| 1123| 0| 32|
0| 1681| 0| 13| 878475| 878538|
897278| 0.00| 0.00
% | 0.0| +0.1| -12.3| +14.6| 0| 0.0|
0| 0.0| 0| 0.0| +0.1| +0.1|
-0.6| 0| 0
1 100| 64| 14697.50| 14.31| 1029| 0| 34|
0| 1830| 0| 13| 881930| 881991|
903837| 0.00| 0.00
2 100| 64| 14692.35| 13.08| 1128| 0| 34|
0| 1830| 0| 13| 881619| 881679|
898952| 0.00| 0.00
% | 0.0| -0.0| -8.6| +9.6| 0| 0.0|
0| 0.0| 0| 0.0| -0.0| -0.0|
-0.5| 0| 0
1 250| 64| 14683.40| 14.34| 1027| 0| 32|
0| 1698| 0| 13| 881083| 881147|
903071| 0.00| 0.00
2 250| 64| 14677.06| 12.85| 1144| 0| 32|
0| 1698| 0| 13| 880702| 880762|
898190| 0.00| 0.00
% | 0.0| -0.0| -10.4| +11.4| 0| 0.0|
0| 0.0| 0| 0.0| -0.0| -0.0|
-0.5| 0| 0
1 500| 64| 14698.45| 14.39| 1025| 0| 34|
0| 1830| 0| 13| 881985| 882060|
905537| 0.00| 0.00
2 500| 64| 14626.17| 13.54| 1083| 0| 34|
0| 1830| 0| 13| 877648| 877726|
896427| 0.00| 0.00
% | 0.0| -0.5| -5.9| +5.7| 0| 0.0|
0| 0.0| 0| 0.0| -0.5| -0.5|
-1.0| 0| 0
1 50| 256| 14386.52| 14.14| 1018| 0| 33|
0| 1716| 0| 13| 863266| 863336|
887195| 0.00| 0.00
2 50| 256| 14359.26| 14.22| 1016| 0| 32|
0| 1681| 0| 13| 861630| 861698|
882444| 0.00| 0.00
% | 0.0| -0.2| +0.6| -0.2| 0| -3.0|
0| -2.0| 0| 0.0| -0.2| -0.2|
-0.5| 0| 0
1 100| 256| 14364.89| 14.25| 1008| 0| 34|
0| 1813| 0| 13| 861969| 862033|
886679| 0.00| 0.00
2 100| 256| 14393.82| 14.53| 999| 0| 34|
0| 1813| 0| 13| 863704| 863765|
884487| 0.00| 0.00
% | 0.0| +0.2| +2.0| -0.9| 0| 0.0|
0| 0.0| 0| 0.0| +0.2| +0.2|
-0.2| 0| 0
1 250| 256| 14387.95| 14.05| 1024| 0| 32|
0| 1681| 0| 13| 863352| 863429|
887505| 0.00| 0.00
2 250| 256| 14344.74| 14.62| 987| 0| 32|
0| 1698| 0| 13| 860760| 860843|
882154| 0.00| 0.00
% | 0.0| -0.3| +4.1| -3.6| 0| 0.0|
0| +1.0| 0| 0.0| -0.3| -0.3|
-0.6| 0| 0
1 500| 256| 14365.89| 14.19| 1013| 0| 33|
0| 1769| 0| 13| 862029| 862099|
885852| 0.00| 0.00
2 500| 256| 14329.59| 14.62| 990| 0| 34|
0| 1830| 0| 13| 859852| 861233|
880082| 0.00| 0.00
% | 0.0| -0.3| +3.0| -2.3| 0| +3.0|
0| +3.4| 0| 0.0| -0.3| -0.1|
-0.7| 0| 0
1 50| 512| 14273.07| 14.12| 1010| 0| 33|
0| 1742| 0| 13| 856460| 856524|
880356| 0.00| 0.00
2 50| 512| 14222.08| 14.72| 966| 0| 32|
0| 1698| 0| 12| 853398| 853468|
875621| 0.00| 0.00
% | 0.0| -0.4| +4.2| -4.4| 0| -3.0|
0| -2.5| 0| -7.7| -0.4| -0.4|
-0.5| 0| 0
1 100| 512| 14236.34| 14.51| 982| 0| 34|
0| 1804| 0| 13| 854258| 854335|
876662| 0.00| 0.00
2 100| 512| 14147.89| 14.85| 953| 0| 34|
0| 1813| 0| 13| 848947| 849031|
871773| 0.00| 0.00
% | 0.0| -0.6| +2.3| -3.0| 0| 0.0|
0| +0.5| 0| 0.0| -0.6| -0.6|
-0.6| 0| 0
1 250| 512| 14260.79| 14.53| 983| 0| 33|
0| 1760| 0| 13| 855721| 855791|
879099| 0.00| 0.00
2 250| 512| 14190.68| 14.87| 954| 0| 32|
0| 1698| 0| 13| 851517| 851580|
874119| 0.00| 0.00
% | 0.0| -0.5| +2.3| -3.0| 0| -3.0|
0| -3.5| 0| 0.0| -0.5| -0.5|
-0.6| 0| 0
1 500| 512| 14273.71| 14.18| 1008| 0| 33|
0| 1769| 0| 13| 856499| 856562|
879984| 0.00| 0.00
2 500| 512| 14213.87| 14.72| 967| 0| 34|
0| 1830| 0| 13| 852907| 852976|
875328| 0.00| 0.00
% | 0.0| -0.4| +3.8| -4.1| 0| +3.0|
0| +3.4| 0| 0.0| -0.4| -0.4|
-0.5| 0| 0
1 50| 1024| 14049.77| 13.89| 1024| 0| 32|
0| 1708| 0| 12| 843061| 843134|
863697| 0.00| 0.00
2 50| 1024| 13980.25| 14.38| 980| 0| 32|
0| 1698| 0| 12| 838890| 838973|
858350| 0.00| 0.00
% | 0.0| -0.5| +3.5| -4.3| 0| 0.0|
0| -0.6| 0| 0.0| -0.5| -0.5|
-0.6| 0| 0
1 100| 1024| 14025.66| 13.32| 1066| 0| 33|
0| 1769| 0| 13| 841616| 841685|
864460| 0.00| 0.00
2 100| 1024| 13993.30| 14.82| 946| 0| 34|
0| 1830| 0| 12| 839676| 839735|
859288| 0.00| 0.00
% | 0.0| -0.2| +11.3| -11.3| 0| +3.0|
0| +3.4| 0| -7.7| -0.2| -0.2|
-0.6| 0| 0
1 250| 1024| 14060.15| 13.90| 1023| 0| 35|
0| 1848| 0| 12| 843688| 843752|
864475| 0.00| 0.00
2 250| 1024| 13982.47| 15.34| 913| 0| 34|
0| 1830| 0| 12| 839026| 839089|
859914| 0.00| 0.00
% | 0.0| -0.6| +10.4| -10.8| 0| -2.9|
0| -1.0| 0| 0.0| -0.6| -0.6|
-0.5| 0| 0
1 500| 1024| 14051.14| 13.80| 1024| 0| 33|
0| 1716| 0| 13| 843144| 843212|
862981| 0.00| 0.00
2 500| 1024| 14013.95| 15.27| 918| 0| 32|
0| 1681| 0| 13| 840915| 840983|
862635| 0.00| 0.00
% | 0.0| -0.3| +10.7| -10.4| 0| -3.0|
0| -2.0| 0| 0.0| -0.3| -0.3|
-0.0| 0| 0
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Rusty Russell @ 2011-12-19 2:35 UTC (permalink / raw)
To: Amos Kong
Cc: kvm, Michael S. Tsirkin, Benjamin Herrenschmidt, linux-kernel,
virtualization, Linus Torvalds, linux-arm-kernel
In-Reply-To: <4EE694B4.5090800@redhat.com>
On Tue, 13 Dec 2011 07:56:36 +0800, Amos Kong <akong@redhat.com> wrote:
> On 12/12/2011 01:12 PM, Rusty Russell wrote:
> > On Mon, 12 Dec 2011 11:06:53 +0800, Amos Kong <akong@redhat.com> wrote:
> >> On 12/12/11 06:27, Benjamin Herrenschmidt wrote:
> >>> On Sun, 2011-12-11 at 14:25 +0200, Michael S. Tsirkin wrote:
> >>>
> >>>> Forwarding some results by Amos, who run multiple netperf streams in
> >>>> parallel, from an external box to the guest. TCP_STREAM results were
> >>>> noisy. This could be due to buffering done by TCP, where packet size
> >>>> varies even as message size is constant.
> >>>>
> >>>> TCP_RR results were consistent. In this benchmark, after switching
> >>>> to mandatory barriers, CPU utilization increased by up to 35% while
> >>>> throughput went down by up to 14%. the normalized throughput/cpu
> >>>> regressed consistently, between 7 and 35%
> >>>>
> >>>> The "fix" applied was simply this:
> >>>
> >>> What machine& processor was this ?
> >>
> >> pined guest memory to numa node 1
> >
> > Please try this patch. How much does the branch cost us?
>
> Ok, I will provide the result later.
Any news? We're cutting it very fine. I've CC'd Linus so he knows this
is coming...
From: Rusty Russell <rusty@rustcorp.com.au>
Subject: virtio: harsher barriers for virtio-mmio.
We were cheating with our barriers; using the smp ones rather than the
real device ones. That was fine, until virtio-mmio came along, which
could be talking to a real device (a non-SMP CPU).
Unfortunately, just putting back the real barriers (reverting
d57ed95d) causes a performance regression on virtio-pci. In
particular, Amos reports netbench's TCP_RR over virtio_net CPU
utilization increased up to 35% while throughput went down by up to
14%.
By comparison, this branch costs us???
Reference: https://lkml.org/lkml/2011/12/11/22
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
---
drivers/lguest/lguest_device.c | 10 ++++++----
drivers/s390/kvm/kvm_virtio.c | 2 +-
drivers/virtio/virtio_mmio.c | 7 ++++---
drivers/virtio/virtio_pci.c | 4 ++--
drivers/virtio/virtio_ring.c | 34 +++++++++++++++++++++-------------
include/linux/virtio_ring.h | 1 +
tools/virtio/linux/virtio.h | 1 +
tools/virtio/virtio_test.c | 3 ++-
8 files changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
@@ -291,11 +291,13 @@ static struct virtqueue *lg_find_vq(stru
}
/*
- * OK, tell virtio_ring.c to set up a virtqueue now we know its size
- * and we've got a pointer to its pages.
+ * OK, tell virtio_ring.c to set up a virtqueue now we know its size
+ * and we've got a pointer to its pages. Note that we set weak_barriers
+ * to 'true': the host just a(nother) SMP CPU, so we only need inter-cpu
+ * barriers.
*/
- vq = vring_new_virtqueue(lvq->config.num, LGUEST_VRING_ALIGN,
- vdev, lvq->pages, lg_notify, callback, name);
+ vq = vring_new_virtqueue(lvq->config.num, LGUEST_VRING_ALIGN, vdev,
+ true, lvq->pages, lg_notify, callback, name);
if (!vq) {
err = -ENOMEM;
goto unmap;
diff --git a/drivers/s390/kvm/kvm_virtio.c b/drivers/s390/kvm/kvm_virtio.c
--- a/drivers/s390/kvm/kvm_virtio.c
+++ b/drivers/s390/kvm/kvm_virtio.c
@@ -198,7 +198,7 @@ static struct virtqueue *kvm_find_vq(str
goto out;
vq = vring_new_virtqueue(config->num, KVM_S390_VIRTIO_RING_ALIGN,
- vdev, (void *) config->address,
+ vdev, true, (void *) config->address,
kvm_notify, callback, name);
if (!vq) {
err = -ENOMEM;
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -309,9 +309,10 @@ static struct virtqueue *vm_setup_vq(str
writel(virt_to_phys(info->queue) >> PAGE_SHIFT,
vm_dev->base + VIRTIO_MMIO_QUEUE_PFN);
- /* Create the vring */
- vq = vring_new_virtqueue(info->num, VIRTIO_MMIO_VRING_ALIGN,
- vdev, info->queue, vm_notify, callback, name);
+ /* Create the vring: no weak barriers, the other side is could
+ * be an independent "device". */
+ vq = vring_new_virtqueue(info->num, VIRTIO_MMIO_VRING_ALIGN, vdev,
+ false, info->queue, vm_notify, callback, name);
if (!vq) {
err = -ENOMEM;
goto error_new_virtqueue;
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
--- a/drivers/virtio/virtio_pci.c
+++ b/drivers/virtio/virtio_pci.c
@@ -414,8 +414,8 @@ static struct virtqueue *setup_vq(struct
vp_dev->ioaddr + VIRTIO_PCI_QUEUE_PFN);
/* create the vring */
- vq = vring_new_virtqueue(info->num, VIRTIO_PCI_VRING_ALIGN,
- vdev, info->queue, vp_notify, callback, name);
+ vq = vring_new_virtqueue(info->num, VIRTIO_PCI_VRING_ALIGN, vdev,
+ true, info->queue, vp_notify, callback, name);
if (!vq) {
err = -ENOMEM;
goto out_activate_queue;
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -28,17 +28,20 @@
#ifdef CONFIG_SMP
/* Where possible, use SMP barriers which are more lightweight than mandatory
* barriers, because mandatory barriers control MMIO effects on accesses
- * through relaxed memory I/O windows (which virtio does not use). */
-#define virtio_mb() smp_mb()
-#define virtio_rmb() smp_rmb()
-#define virtio_wmb() smp_wmb()
+ * through relaxed memory I/O windows (which virtio-pci does not use). */
+#define virtio_mb(vq) \
+ do { if ((vq)->weak_barriers) smp_mb(); else mb(); } while(0)
+#define virtio_rmb(vq) \
+ do { if ((vq)->weak_barriers) smp_rmb(); else rmb(); } while(0)
+#define virtio_wmb(vq) \
+ do { if ((vq)->weak_barriers) smp_rmb(); else rmb(); } while(0)
#else
/* We must force memory ordering even if guest is UP since host could be
* running on another CPU, but SMP barriers are defined to barrier() in that
* configuration. So fall back to mandatory barriers instead. */
-#define virtio_mb() mb()
-#define virtio_rmb() rmb()
-#define virtio_wmb() wmb()
+#define virtio_mb(vq) mb()
+#define virtio_rmb(vq) rmb()
+#define virtio_wmb(vq) wmb()
#endif
#ifdef DEBUG
@@ -77,6 +80,9 @@ struct vring_virtqueue
/* Actual memory layout for this queue */
struct vring vring;
+ /* Can we use weak barriers? */
+ bool weak_barriers;
+
/* Other side has made a mess, don't try any more. */
bool broken;
@@ -245,14 +251,14 @@ void virtqueue_kick(struct virtqueue *_v
START_USE(vq);
/* Descriptors and available array need to be set before we expose the
* new available array entries. */
- virtio_wmb();
+ virtio_wmb(vq);
old = vq->vring.avail->idx;
new = vq->vring.avail->idx = old + vq->num_added;
vq->num_added = 0;
/* Need to update avail index before checking if we should notify */
- virtio_mb();
+ virtio_mb(vq);
if (vq->event ?
vring_need_event(vring_avail_event(&vq->vring), new, old) :
@@ -314,7 +320,7 @@ void *virtqueue_get_buf(struct virtqueue
}
/* Only get used array entries after they have been exposed by host. */
- virtio_rmb();
+ virtio_rmb(vq);
i = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].id;
*len = vq->vring.used->ring[vq->last_used_idx%vq->vring.num].len;
@@ -337,7 +343,7 @@ void *virtqueue_get_buf(struct virtqueue
* the read in the next get_buf call. */
if (!(vq->vring.avail->flags & VRING_AVAIL_F_NO_INTERRUPT)) {
vring_used_event(&vq->vring) = vq->last_used_idx;
- virtio_mb();
+ virtio_mb(vq);
}
END_USE(vq);
@@ -366,7 +372,7 @@ bool virtqueue_enable_cb(struct virtqueu
* entry. Always do both to keep code simple. */
vq->vring.avail->flags &= ~VRING_AVAIL_F_NO_INTERRUPT;
vring_used_event(&vq->vring) = vq->last_used_idx;
- virtio_mb();
+ virtio_mb(vq);
if (unlikely(more_used(vq))) {
END_USE(vq);
return false;
@@ -393,7 +399,7 @@ bool virtqueue_enable_cb_delayed(struct
/* TODO: tune this threshold */
bufs = (u16)(vq->vring.avail->idx - vq->last_used_idx) * 3 / 4;
vring_used_event(&vq->vring) = vq->last_used_idx + bufs;
- virtio_mb();
+ virtio_mb(vq);
if (unlikely((u16)(vq->vring.used->idx - vq->last_used_idx) > bufs)) {
END_USE(vq);
return false;
@@ -453,6 +459,7 @@ EXPORT_SYMBOL_GPL(vring_interrupt);
struct virtqueue *vring_new_virtqueue(unsigned int num,
unsigned int vring_align,
struct virtio_device *vdev,
+ bool weak_barriers,
void *pages,
void (*notify)(struct virtqueue *),
void (*callback)(struct virtqueue *),
@@ -476,6 +483,7 @@ struct virtqueue *vring_new_virtqueue(un
vq->vq.vdev = vdev;
vq->vq.name = name;
vq->notify = notify;
+ vq->weak_barriers = weak_barriers;
vq->broken = false;
vq->last_used_idx = 0;
vq->num_added = 0;
diff --git a/include/linux/virtio_ring.h b/include/linux/virtio_ring.h
--- a/include/linux/virtio_ring.h
+++ b/include/linux/virtio_ring.h
@@ -168,6 +168,7 @@ struct virtqueue;
struct virtqueue *vring_new_virtqueue(unsigned int num,
unsigned int vring_align,
struct virtio_device *vdev,
+ bool weak_barriers,
void *pages,
void (*notify)(struct virtqueue *vq),
void (*callback)(struct virtqueue *vq),
diff --git a/tools/virtio/linux/virtio.h b/tools/virtio/linux/virtio.h
--- a/tools/virtio/linux/virtio.h
+++ b/tools/virtio/linux/virtio.h
@@ -214,6 +214,7 @@ void *virtqueue_detach_unused_buf(struct
struct virtqueue *vring_new_virtqueue(unsigned int num,
unsigned int vring_align,
struct virtio_device *vdev,
+ bool weak_barriers,
void *pages,
void (*notify)(struct virtqueue *vq),
void (*callback)(struct virtqueue *vq),
diff --git a/tools/virtio/virtio_test.c b/tools/virtio/virtio_test.c
--- a/tools/virtio/virtio_test.c
+++ b/tools/virtio/virtio_test.c
@@ -92,7 +92,8 @@ static void vq_info_add(struct vdev_info
assert(r >= 0);
memset(info->ring, 0, vring_size(num, 4096));
vring_init(&info->vring, num, info->ring, 4096);
- info->vq = vring_new_virtqueue(info->vring.num, 4096, &dev->vdev, info->ring,
+ info->vq = vring_new_virtqueue(info->vring.num, 4096, &dev->vdev,
+ true, info->ring,
vq_notify, vq_callback, "test");
assert(info->vq);
info->vq->priv = info;
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Benjamin Herrenschmidt @ 2011-12-19 2:41 UTC (permalink / raw)
To: Amos Kong
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization, rhod,
linux-arm-kernel
In-Reply-To: <4EEE9F16.8000501@redhat.com>
On Mon, 2011-12-19 at 10:19 +0800, Amos Kong wrote:
> I tested with the same environment and scenarios.
> tested one scenarios for three times and compute the average for more
> precision.
>
> Thanks, Amos
>
> --------- compare results -----------
> Mon Dec 19 09:51:09 2011
>
> 1 - avg-old.netperf.exhost_guest.txt
> 2 - avg-fixed.netperf.exhost_guest.txt
The output is word wrapped and generally unreadable. Any chance you can
provide us with a summary of the outcome ?
Cheers,
Ben.
> ======
> TCP_STREAM
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 1| 64| 1073.54| 10.50| 102| 0| 31|
> 0| 1612| 0| 16| 487641| 489753|
> 504764| 0.00| 0.00
> 2 1| 64| 1079.44| 10.29| 104| 0| 30|
> 0| 1594| 0| 17| 487156| 488828|
> 504411| 0.00| 0.00
> % | 0.0| +0.5| -2.0| +2.0| 0| -3.2|
> 0| -1.1| 0| +6.2| -0.1| -0.2|
> -0.1| 0| 0
> 1 2| 64| 2141.12| 15.72| 136| 0| 33|
> 0| 1744| 0| 34| 873777| 972303|
> 928926| 0.00| 0.00
> 2 2| 64| 2140.88| 15.64| 137| 0| 33|
> 0| 1744| 0| 34| 926588| 942841|
> 974095| 0.00| 0.00
> % | 0.0| -0.0| -0.5| +0.7| 0| 0.0|
> 0| 0.0| 0| 0.0| +6.0| -3.0|
> +4.9| 0| 0
> 1 4| 64| 4076.80| 19.82| 205| 0| 30|
> 0| 1577| 0| 67| 1422282| 1166425|
> 1539219| 0.00| 0.00
> 2 4| 64| 4094.32| 20.70| 197| 0| 31|
> 0| 1612| 0| 68| 1704330| 1314077|
> 1833394| 0.00| 0.00
> % | 0.0| +0.4| +4.4| -3.9| 0| +3.3|
> 0| +2.2| 0| +1.5| +19.8| +12.7|
> +19.1| 0| 0
> 1 1| 256| 2867.48| 13.44| 213| 0| 32|
> 0| 1726| 0| 14| 666430| 694922|
> 690730| 0.00| 0.00
> 2 1| 256| 2874.20| 12.71| 226| 0| 32|
> 0| 1709| 0| 14| 697960| 740407|
> 721807| 0.00| 0.00
> % | 0.0| +0.2| -5.4| +6.1| 0| 0.0|
> 0| -1.0| 0| 0.0| +4.7| +6.5|
> +4.5| 0| 0
> 1 2| 256| 5642.82| 17.61| 320| 0| 30|
> 0| 1594| 0| 30| 1226861| 1236081|
> 1268562| 0.00| 0.00
> 2 2| 256| 5661.06| 17.41| 326| 0| 30|
> 0| 1594| 0| 29| 1175696| 1143490|
> 1221528| 0.00| 0.00
> % | 0.0| +0.3| -1.1| +1.9| 0| 0.0|
> 0| 0.0| 0| -3.3| -4.2| -7.5|
> -3.7| 0| 0
> 1 4| 256| 9404.27| 23.55| 399| 0| 33|
> 0| 1744| 0| 37| 1692245| 659975|
> 1765103| 0.00| 0.00
> 2 4| 256| 8761.11| 23.18| 376| 0| 32|
> 0| 1726| 0| 36| 1699382| 418992|
> 1870804| 0.00| 0.00
> % | 0.0| -6.8| -1.6| -5.8| 0| -3.0|
> 0| -1.0| 0| -2.7| +0.4| -36.5|
> +6.0| 0| 0
> 1 1| 512| 3803.66| 14.20| 267| 0| 30|
> 0| 1594| 0| 14| 693992| 750078|
> 721107| 0.00| 0.00
> 2 1| 512| 3838.02| 15.47| 248| 0| 31|
> 0| 1612| 0| 15| 811709| 773505|
> 838788| 0.00| 0.00
> % | 0.0| +0.9| +8.9| -7.1| 0| +3.3|
> 0| +1.1| 0| +7.1| +17.0| +3.1|
> +16.3| 0| 0
> 1 2| 512| 8606.11| 19.34| 444| 0| 32|
> 0| 1709| 0| 29| 1264624| 647652|
> 1309740| 0.00| 0.00
> 2 2| 512| 8127.80| 18.93| 428| 0| 32|
> 0| 1726| 0| 28| 1216606| 1179269|
> 1266260| 0.00| 0.00
> % | 0.0| -5.6| -2.1| -3.6| 0| 0.0|
> 0| +1.0| 0| -3.4| -3.8| +82.1|
> -3.3| 0| 0
> 1 4| 512| 9409.41| 22.88| 413| 0| 30|
> 0| 1577| 0| 35| 1592587| 1072862|
> 1746787| 0.00| 0.00
> 2 4| 512| 9217.34| 23.05| 400| 0| 30|
> 0| 1594| 0| 34| 1596515| 513742|
> 1831538| 0.00| 0.00
> % | 0.0| -2.0| +0.7| -3.1| 0| 0.0|
> 0| +1.1| 0| -2.9| +0.2| -52.1|
> +4.9| 0| 0
> 1 1| 1024| 4389.75| 14.62| 303| 0| 32|
> 0| 1726| 0| 14| 663417| 611555|
> 689028| 0.00| 0.00
> 2 1| 1024| 4390.44| 13.66| 321| 0| 32|
> 0| 1726| 0| 13| 609836| 556090|
> 634511| 0.00| 0.00
> % | 0.0| +0.0| -6.6| +5.9| 0| 0.0|
> 0| 0.0| 0| -7.1| -8.1| -9.1|
> -7.9| 0| 0
> 1 2| 1024| 9046.18| 19.63| 460| 0| 30|
> 0| 1594| 0| 28| 1206853| 1054653|
> 1256203| 0.00| 0.00
> 2 2| 1024| 9027.54| 20.15| 447| 0| 30|
> 0| 1577| 0| 27| 1179555| 884408|
> 1226843| 0.00| 0.00
> % | 0.0| -0.2| +2.6| -2.8| 0| 0.0|
> 0| -1.1| 0| -3.6| -2.3| -16.1|
> -2.3| 0| 0
> 1 4| 1024| 9410.41| 22.01| 427| 0| 32|
> 0| 1726| 0| 36| 1734433| 887190|
> 1852486| 0.00| 0.00
> 2 4| 1024| 9409.11| 23.18| 405| 0| 32|
> 0| 1726| 0| 34| 1695359| 625268|
> 1803599| 0.00| 0.00
> % | 0.0| -0.0| +5.3| -5.2| 0| 0.0|
> 0| 0.0| 0| -5.6| -2.3| -29.5|
> -2.6| 0| 0
> TCP_MAERTS
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 1| 64| 1056.13| 17.51| 59| 0| 30|
> 0| 1594| 3| 86| 476098| 4780186|
> 538158| 0.00| 0.00
> 2 1| 64| 1065.51| 17.64| 60| 0| 30|
> 0| 1594| 3| 87| 476836| 4823602|
> 538860| 0.00| 0.00
> % | 0.0| +0.9| +0.7| +1.7| 0| 0.0|
> 0| 0.0| 0.0| +1.2| +0.2| +0.9|
> +0.1| 0| 0
> 1 2| 64| 2472.80| 32.18| 76| 0| 32|
> 0| 1709| 2| 199| 479119| 2089931|
> 600119| 0.00| 0.00
> 2 2| 64| 2468.76| 32.28| 76| 0| 33|
> 0| 1744| 1| 199| 479372| 2179342|
> 600328| 0.00| 0.00
> % | 0.0| -0.2| +0.3| 0.0| 0| +3.1|
> 0| +2.0| -50.0| 0.0| +0.1| +4.3|
> +0.0| 0| 0
> 1 4| 64| 2453.22| 32.20| 75| 0| 31|
> 0| 1612| 2| 198| 479223| 2175801|
> 600081| 0.00| 0.00
> 2 4| 64| 2465.68| 32.30| 76| 0| 30|
> 0| 1594| 3| 200| 479404| 2108293|
> 600252| 0.00| 0.00
> % | 0.0| +0.5| +0.3| +1.3| 0| -3.2|
> 0| -1.1| +50.0| +1.0| +0.0| -3.1|
> +0.0| 0| 0
> 1 1| 256| 3608.37| 24.59| 146| 0| 32|
> 0| 1726| 2| 277| 88346| 108310|
> 150637| 0.00| 0.00
> 2 1| 256| 3611.12| 24.95| 144| 0| 32|
> 0| 1709| 0| 281| 83319| 64354|
> 145511| 0.00| 0.00
> % | 0.0| +0.1| +1.5| -1.4| 0| 0.0|
> 0| -1.0| -100.0| +1.4| -5.7| -40.6|
> -3.4| 0| 0
> 1 2| 256| 7373.32| 26.83| 274| 0| 31|
> 0| 1612| 0| 4185| 278932| 264031|
> 377267| 0.00| 0.00
> 2 2| 256| 7460.03| 26.93| 276| 0| 30|
> 0| 1594| 1| 5913| 270840| 246165|
> 371999| 0.00| 0.00
> % | 0.0| +1.2| +0.4| +0.7| 0| -3.2|
> 0| -1.1| 0| +41.3| -2.9| -6.8|
> -1.4| 0| 0
> 1 4| 256| 9322.66| 29.73| 313| 0| 32|
> 0| 1709| 848| 3041| 363114| 329308|
> 482586| 0.00| 0.00
> 2 4| 256| 9365.52| 29.59| 316| 0| 33|
> 0| 1744| 414| 2884| 371485| 339191|
> 491366| 0.00| 0.00
> % | 0.0| +0.5| -0.5| +1.0| 0| +3.1|
> 0| +2.0| -51.2| -5.2| +2.3| +3.0|
> +1.8| 0| 0
> 1 1| 512| 9360.25| 17.20| 543| 0| 30|
> 0| 1577| 0| 387| 438621| 408062|
> 499989| 0.00| 0.00
> 2 1| 512| 8899.37| 18.17| 495| 0| 30|
> 0| 1594| 0| 5049| 393341| 371545|
> 459397| 0.00| 0.00
> % | 0.0| -4.9| +5.6| -8.8| 0| 0.0|
> 0| +1.1| 0| +1204.7| -10.3| -8.9|
> -8.1| 0| 0
> 1 2| 512| 8713.11| 20.77| 420| 0| 32|
> 0| 1726| 0| 11227| 296157| 246495|
> 371632| 0.00| 0.00
> 2 2| 512| 8686.31| 20.72| 421| 0| 32|
> 0| 1709| 0| 11002| 296608| 246597|
> 371797| 0.00| 0.00
> % | 0.0| -0.3| -0.2| +0.2| 0| 0.0|
> 0| -1.0| 0| -2.0| +0.2| +0.0|
> +0.0| 0| 0
> 1 4| 512| 8780.40| 22.72| 386| 0| 30|
> 0| 1594| 0| 10337| 303619| 249822|
> 385457| 0.00| 0.00
> 2 4| 512| 8858.51| 22.66| 390| 0| 30|
> 0| 1577| 0| 9968| 301847| 246543|
> 382121| 0.00| 0.00
> % | 0.0| +0.9| -0.3| +1.0| 0| 0.0|
> 0| -1.1| 0| -3.6| -0.6| -1.3|
> -0.9| 0| 0
> 1 1| 1024| 9387.09| 16.43| 571| 0| 32|
> 0| 1726| 0| 84| 452351| 429483|
> 504022| 0.00| 0.00
> 2 1| 1024| 9388.90| 16.51| 568| 0| 32|
> 0| 1726| 2| 76| 446994| 422489|
> 499025| 0.00| 0.00
> % | 0.0| +0.0| +0.5| -0.5| 0| 0.0|
> 0| 0.0| 0| -9.5| -1.2| -1.6|
> -1.0| 0| 0
> 1 2| 1024| 9361.43| 17.26| 542| 0| 30|
> 0| 1594| 5| 647| 388626| 358303|
> 442125| 0.00| 0.00
> 2 2| 1024| 9364.78| 17.25| 542| 0| 31|
> 0| 1612| 35| 554| 389326| 360169|
> 442343| 0.00| 0.00
> % | 0.0| +0.0| -0.1| 0.0| 0| +3.3|
> 0| +1.1| +600.0| -14.4| +0.2| +0.5|
> +0.0| 0| 0
> 1 4| 1024| 9381.57| 18.35| 510| 0| 32|
> 0| 1726| 1189| 648| 405900| 376269|
> 459845| 0.00| 0.00
> 2 4| 1024| 9393.48| 18.27| 513| 0| 32|
> 0| 1726| 1754| 610| 402132| 373768|
> 455629| 0.00| 0.00
> % | 0.0| +0.1| -0.4| +0.6| 0| 0.0|
> 0| 0.0| +47.5| -5.9| -0.9| -0.7|
> -0.9| 0| 0
> TCP_RR
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 50| 64| 10903.70| 8.03| 1382| 0| 32|
> 0| 1698| 0| 9| 654298| 654362|
> 665532| 0.00| 0.00
> 2 50| 64| 10880.50| 7.40| 1488| 0| 32|
> 0| 1698| 0| 10| 652907| 652973|
> 667042| 0.00| 0.00
> % | 0.0| -0.2| -7.8| +7.7| 0| 0.0|
> 0| 0.0| 0| +11.1| -0.2| -0.2|
> +0.2| 0| 0
> 1 100| 64| 10953.00| 8.40| 1332| 0| 34|
> 0| 1830| 0| 10| 657257| 657325|
> 667088| 0.00| 0.00
> 2 100| 64| 10882.78| 7.67| 1439| 0| 34|
> 0| 1830| 0| 9| 653044| 653110|
> 668883| 0.00| 0.00
> % | 0.0| -0.6| -8.7| +8.0| 0| 0.0|
> 0| 0.0| 0| -10.0| -0.6| -0.6|
> +0.3| 0| 0
> 1 250| 64| 10902.66| 8.57| 1300| 0| 33|
> 0| 1716| 0| 10| 654235| 654308|
> 665518| 0.00| 0.00
> 2 250| 64| 10866.79| 7.58| 1449| 0| 32|
> 0| 1664| 0| 10| 652083| 652155|
> 666869| 0.00| 0.00
> % | 0.0| -0.3| -11.6| +11.5| 0| -3.0|
> 0| -3.0| 0| 0.0| -0.3| -0.3|
> +0.2| 0| 0
> 1 500| 64| 10924.34| 7.25| 1509| 0| 34|
> 0| 1830| 0| 10| 655536| 655619|
> 665776| 0.00| 0.00
> 2 500| 64| 10927.52| 6.50| 1684| 0| 34|
> 0| 1813| 0| 10| 655726| 655803|
> 668527| 0.00| 0.00
> % | 0.0| +0.0| -10.3| +11.6| 0| 0.0|
> 0| -0.9| 0| 0.0| +0.0| +0.0|
> +0.4| 0| 0
> 1 50| 256| 10407.35| 9.38| 1112| 0| 32|
> 0| 1681| 0| 9| 624516| 624581|
> 639159| 0.00| 0.00
> 2 50| 256| 10422.60| 9.45| 1108| 0| 33|
> 0| 1716| 0| 9| 625432| 625498|
> 641343| 0.00| 0.00
> % | 0.0| +0.1| +0.7| -0.4| 0| +3.1|
> 0| +2.1| 0| 0.0| +0.1| +0.1|
> +0.3| 0| 0
> 1 100| 256| 10404.30| 8.99| 1159| 0| 34|
> 0| 1830| 0| 9| 624335| 624400|
> 637357| 0.00| 0.00
> 2 100| 256| 10442.84| 9.57| 1093| 0| 35|
> 0| 1848| 0| 9| 626650| 626714|
> 639017| 0.00| 0.00
> % | 0.0| +0.4| +6.5| -5.7| 0| +2.9|
> 0| +1.0| 0| 0.0| +0.4| +0.4|
> +0.3| 0| 0
> 1 250| 256| 10427.71| 9.10| 1157| 0| 32|
> 0| 1698| 0| 9| 625738| 625822|
> 641221| 0.00| 0.00
> 2 250| 256| 10464.71| 9.69| 1085| 0| 32|
> 0| 1698| 0| 9| 627960| 628040|
> 640680| 0.00| 0.00
> % | 0.0| +0.4| +6.5| -6.2| 0| 0.0|
> 0| 0.0| 0| 0.0| +0.4| +0.4|
> -0.1| 0| 0
> 1 500| 256| 10442.18| 8.65| 1217| 0| 34|
> 0| 1830| 0| 10| 626608| 626675|
> 640081| 0.00| 0.00
> 2 500| 256| 10463.74| 9.63| 1089| 0| 34|
> 0| 1813| 0| 9| 627904| 627967|
> 643152| 0.00| 0.00
> % | 0.0| +0.2| +11.3| -10.5| 0| 0.0|
> 0| -0.9| 0| -10.0| +0.2| +0.2|
> +0.5| 0| 0
> 1 50| 512| 8505.70| 7.20| 1191| 0| 33|
> 0| 1716| 0| 7| 510418| 510486|
> 524904| 0.00| 0.00
> 2 50| 512| 8563.34| 7.24| 1185| 0| 32|
> 0| 1664| 0| 8| 513877| 513940|
> 526294| 0.00| 0.00
> % | 0.0| +0.7| +0.6| -0.5| 0| -3.0|
> 0| -3.0| 0| +14.3| +0.7| +0.7|
> +0.3| 0| 0
> 1 100| 512| 8509.97| 7.00| 1226| 0| 34|
> 0| 1830| 0| 7| 510674| 510756|
> 525205| 0.00| 0.00
> 2 100| 512| 8555.22| 7.52| 1144| 0| 34|
> 0| 1830| 0| 7| 513389| 513471|
> 526609| 0.00| 0.00
> % | 0.0| +0.5| +7.4| -6.7| 0| 0.0|
> 0| 0.0| 0| 0.0| +0.5| +0.5|
> +0.3| 0| 0
> 1 250| 512| 8507.35| 7.21| 1183| 0| 32|
> 0| 1681| 0| 7| 510518| 510579|
> 524294| 0.00| 0.00
> 2 250| 512| 8578.13| 7.01| 1223| 0| 33|
> 0| 1716| 0| 8| 514765| 514829|
> 526481| 0.00| 0.00
> % | 0.0| +0.8| -2.8| +3.4| 0| +3.1|
> 0| +2.1| 0| +14.3| +0.8| +0.8|
> +0.4| 0| 0
> 1 500| 512| 8521.68| 6.54| 1302| 0| 34|
> 0| 1813| 0| 8| 511375| 511443|
> 523357| 0.00| 0.00
> 2 500| 512| 8573.17| 6.94| 1235| 0| 34|
> 0| 1830| 0| 7| 514467| 514533|
> 526131| 0.00| 0.00
> % | 0.0| +0.6| +6.1| -5.1| 0| 0.0|
> 0| +0.9| 0| -12.5| +0.6| +0.6|
> +0.5| 0| 0
> 1 50| 1024| 8150.01| 7.69| 1060| 0| 32|
> 0| 1681| 0| 7| 489075| 489155|
> 503136| 0.00| 0.00
> 2 50| 1024| 8129.35| 7.65| 1062| 0| 34|
> 0| 1804| 0| 7| 487841| 487915|
> 502061| 0.00| 0.00
> % | 0.0| -0.3| -0.5| +0.2| 0| +6.2|
> 0| +7.3| 0| 0.0| -0.3| -0.3|
> -0.2| 0| 0
> 1 100| 1024| 8166.06| 7.53| 1083| 0| 34|
> 0| 1804| 0| 7| 490039| 490104|
> 502990| 0.00| 0.00
> 2 100| 1024| 8118.23| 7.77| 1044| 0| 33|
> 0| 1725| 0| 7| 487171| 487236|
> 501939| 0.00| 0.00
> % | 0.0| -0.6| +3.2| -3.6| 0| -2.9|
> 0| -4.4| 0| 0.0| -0.6| -0.6|
> -0.2| 0| 0
> 1 250| 1024| 8175.35| 7.58| 1079| 0| 35|
> 0| 1848| 0| 7| 490597| 490657|
> 503641| 0.00| 0.00
> 2 250| 1024| 8146.63| 7.59| 1072| 0| 34|
> 0| 1813| 0| 7| 488874| 488939|
> 502010| 0.00| 0.00
> % | 0.0| -0.4| +0.1| -0.6| 0| -2.9|
> 0| -1.9| 0| 0.0| -0.4| -0.4|
> -0.3| 0| 0
> 1 500| 1024| 8182.51| 7.61| 1075| 0| 32|
> 0| 1698| 0| 7| 491028| 491095|
> 504222| 0.00| 0.00
> 2 500| 1024| 8157.39| 7.58| 1075| 0| 33|
> 0| 1716| 0| 7| 489521| 489593|
> 502368| 0.00| 0.00
> % | 0.0| -0.3| -0.4| 0.0| 0| +3.1|
> 0| +1.1| 0| 0.0| -0.3| -0.3|
> -0.4| 0| 0
>
> Mon Dec 19 09:51:09 2011
>
> 1 - avg-old.netperf.host_guest.txt
> 2 - avg-fixed.netperf.host_guest.txt
>
> ======
> TCP_STREAM
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 1| 64| 715.76| 28.44| 24| 0| 31|
> 0| 1629| 0| 36| 3206862| 1733540|
> 3245171| 0.00| 0.00
> 2 1| 64| 714.82| 28.44| 25| 0| 31|
> 0| 1612| 0| 36| 3204256| 1709508|
> 3242450| 0.00| 0.00
> % | 0.0| -0.1| 0.0| +4.2| 0| 0.0|
> 0| -1.0| 0| 0.0| -0.1| -1.4|
> -0.1| 0| 0
> 1 2| 64| 1449.31| 41.23| 35| 0| 33|
> 0| 1744| 0| 66| 2764635| 1667527|
> 2815591| 0.00| 0.00
> 2 2| 64| 1442.92| 41.32| 34| 0| 32|
> 0| 1709| 0| 66| 2751461| 1659498|
> 2799277| 0.00| 0.00
> % | 0.0| -0.4| +0.2| -2.9| 0| -3.0|
> 0| -2.0| 0| 0.0| -0.5| -0.5|
> -0.6| 0| 0
> 1 4| 64| 2671.25| 48.95| 54| 0| 30|
> 0| 1577| 0| 47| 914085| 289771|
> 947054| 0.00| 0.00
> 2 4| 64| 2652.68| 48.20| 54| 0| 30|
> 0| 1594| 0| 46| 882300| 293273|
> 914249| 0.00| 0.00
> % | 0.0| -0.7| -1.5| 0.0| 0| 0.0|
> 0| +1.1| 0| -2.1| -3.5| +1.2|
> -3.5| 0| 0
> 1 1| 256| 1478.61| 29.34| 50| 0| 32|
> 0| 1709| 0| 64| 3502384| 1541681|
> 3545371| 0.00| 0.00
> 2 1| 256| 1481.38| 29.27| 50| 0| 32|
> 0| 1726| 0| 64| 3485623| 1526105|
> 3528343| 0.00| 0.00
> % | 0.0| +0.2| -0.2| 0.0| 0| 0.0|
> 0| +1.0| 0| 0.0| -0.5| -1.0|
> -0.5| 0| 0
> 1 2| 256| 3095.93| 42.31| 72| 0| 31|
> 0| 1612| 0| 123| 1521019| 466426|
> 1637722| 0.00| 0.00
> 2 2| 256| 3098.16| 42.03| 73| 0| 30|
> 0| 1594| 0| 123| 1519458| 472632|
> 1632462| 0.00| 0.00
> % | 0.0| +0.1| -0.7| +1.4| 0| -3.2|
> 0| -1.1| 0| 0.0| -0.1| +1.3|
> -0.3| 0| 0
> 1 4| 256| 6553.60| 38.44| 170| 0| 33|
> 0| 1761| 0| 38| 1343193| 237604|
> 1402385| 0.00| 0.00
> 2 4| 256| 6649.37| 38.34| 172| 0| 32|
> 0| 1726| 0| 32| 1343770| 236320|
> 1400875| 0.00| 0.00
> % | 0.0| +1.5| -0.3| +1.2| 0| -3.0|
> 0| -2.0| 0| -15.8| +0.0| -0.5|
> -0.1| 0| 0
> 1 1| 512| 1818.40| 29.28| 61| 0| 31|
> 0| 1646| 0| 76| 3326887| 1491961|
> 3371189| 0.00| 0.00
> 2 1| 512| 1822.74| 29.45| 61| 0| 30|
> 0| 1577| 0| 76| 3309934| 1470715|
> 3352921| 0.00| 0.00
> % | 0.0| +0.2| +0.6| 0.0| 0| -3.2|
> 0| -4.2| 0| 0.0| -0.5| -1.4|
> -0.5| 0| 0
> 1 2| 512| 3931.72| 43.51| 89| 0| 33|
> 0| 1761| 0| 137| 1148331| 301194|
> 1270351| 0.00| 0.00
> 2 2| 512| 3926.16| 43.45| 90| 0| 32|
> 0| 1726| 0| 135| 1166280| 306110|
> 1288869| 0.00| 0.00
> % | 0.0| -0.1| -0.1| +1.1| 0| -3.0|
> 0| -2.0| 0| -1.5| +1.6| +1.6|
> +1.5| 0| 0
> 1 4| 512| 8634.49| 40.69| 211| 0| 31|
> 0| 1612| 0| 53| 1869998| 353856|
> 1948593| 0.00| 0.00
> 2 4| 512| 9137.12| 40.77| 223| 0| 30|
> 0| 1594| 0| 48| 1879574| 362851|
> 1959044| 0.00| 0.00
> % | 0.0| +5.8| +0.2| +5.7| 0| -3.2|
> 0| -1.1| 0| -9.4| +0.5| +2.5|
> +0.5| 0| 0
> 1 1| 1024| 2042.67| 29.50| 68| 0| 33|
> 0| 1778| 0| 84| 3087032| 1309160|
> 3130736| 0.00| 0.00
> 2 1| 1024| 2033.24| 29.51| 68| 0| 32|
> 0| 1726| 0| 83| 3082898| 1295936|
> 3125229| 0.00| 0.00
> % | 0.0| -0.5| +0.0| 0.0| 0| -3.0|
> 0| -2.9| 0| -1.2| -0.1| -1.0|
> -0.2| 0| 0
> 1 2| 1024| 7703.26| 39.58| 194| 0| 32|
> 0| 1673| 0| 65| 2522172| 663302|
> 2684835| 0.00| 0.00
> 2 2| 1024| 7657.00| 39.27| 194| 0| 30|
> 0| 1594| 0| 62| 2607281| 698035|
> 2755198| 0.00| 0.00
> % | 0.0| -0.6| -0.8| 0.0| 0| -6.2|
> 0| -4.7| 0| -4.6| +3.4| +5.2|
> +2.6| 0| 0
> 1 4| 1024| 11814.84| 39.38| 299| 0| 32|
> 0| 1700| 0| 28| 2510318| 576071|
> 2596631| 0.00| 0.00
> 2 4| 1024| 12871.76| 38.93| 330| 0| 32|
> 0| 1726| 0| 25| 2232437| 632785|
> 2316035| 0.00| 0.00
> % | 0.0| +8.9| -1.1| +10.4| 0| 0.0|
> 0| +1.5| 0| -10.7| -11.1| +9.8|
> -10.8| 0| 0
> TCP_MAERTS
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 1| 64| 706.98| 26.25| 26| 0| 31|
> 0| 1656| 0| 80| 2630204| 4185330|
> 2692397| 0.00| 0.00
> 2 1| 64| 767.45| 27.78| 27| 0| 30|
> 0| 1594| 0| 85| 2626694| 4317273|
> 2688799| 0.00| 0.00
> % | 0.0| +8.6| +5.8| +3.8| 0| -3.2|
> 0| -3.7| 0| +6.2| -0.1| +3.2|
> -0.1| 0| 0
> 1 2| 64| 2644.57| 42.60| 61| 0| 32|
> 0| 1700| 0| 34863| 49057| 16791|
> 204805| 0.00| 0.00
> 2 2| 64| 2721.19| 42.69| 63| 0| 32|
> 0| 1709| 0| 42365| 52739| 20094|
> 215895| 0.00| 0.00
> % | 0.0| +2.9| +0.2| +3.3| 0| 0.0|
> 0| +0.5| 0| +21.5| +7.5| +19.7|
> +5.4| 0| 0
> 1 4| 64| 2756.40| 42.69| 64| 0| 32|
> 0| 1708| 0| 52043| 47976| 12694|
> 220732| 0.00| 0.00
> 2 4| 64| 2709.19| 42.79| 62| 0| 30|
> 0| 1594| 0| 50144| 47275| 12743|
> 218074| 0.00| 0.00
> % | 0.0| -1.7| +0.2| -3.1| 0| -6.2|
> 0| -6.7| 0| -3.6| -1.5| +0.4|
> -1.2| 0| 0
> 1 1| 256| 3785.63| 32.34| 116| 0| 33|
> 0| 1734| 0| 36642| 58940| 1187|
> 157652| 0.00| 0.00
> 2 1| 256| 3593.17| 32.90| 108| 0| 32|
> 0| 1726| 0| 33179| 54980| 1130|
> 150168| 0.00| 0.00
> % | 0.0| -5.1| +1.7| -6.9| 0| -3.0|
> 0| -0.5| 0| -9.5| -6.7| -4.8|
> -4.7| 0| 0
> 1 2| 256| 8316.26| 40.45| 205| 0| 32|
> 0| 1673| 0| 28302| 114835| 1655|
> 251137| 0.00| 0.00
> 2 2| 256| 8390.41| 41.17| 203| 0| 30|
> 0| 1594| 0| 31222| 115372| 1696|
> 257151| 0.00| 0.00
> % | 0.0| +0.9| +1.8| -1.0| 0| -6.2|
> 0| -4.7| 0| +10.3| +0.5| +2.5|
> +2.4| 0| 0
> 1 4| 256| 9672.49| 42.40| 227| 0| 33|
> 0| 1761| 0| 30045| 132027| 3059|
> 283491| 0.00| 0.00
> 2 4| 256| 9741.71| 42.57| 228| 0| 32|
> 0| 1726| 6| 28875| 132125| 1999|
> 283036| 0.00| 0.00
> % | 0.0| +0.7| +0.4| +0.4| 0| -3.0|
> 0| -2.0| 0| -3.9| +0.1| -34.7|
> -0.2| 0| 0
> 1 1| 512| 6052.41| 32.23| 187| 0| 31|
> 0| 1612| 0| 44681| 86084| 2592|
> 187465| 0.00| 0.00
> 2 1| 512| 6267.37| 32.51| 192| 0| 30|
> 0| 1577| 0| 45278| 88449| 2708|
> 191374| 0.00| 0.00
> % | 0.0| +3.6| +0.9| +2.7| 0| -3.2|
> 0| -2.2| 0| +1.3| +2.7| +4.5|
> +2.1| 0| 0
> 1 2| 512| 12714.52| 38.27| 331| 0| 33|
> 0| 1744| 0| 24843| 169170| 2381|
> 292210| 0.00| 0.00
> 2 2| 512| 11341.65| 37.30| 303| 0| 32|
> 0| 1726| 14| 27393| 152465| 2980|
> 270740| 0.00| 0.00
> % | 0.0| -10.8| -2.5| -8.5| 0| -3.0|
> 0| -1.0| 0| +10.3| -9.9| +25.2|
> -7.3| 0| 0
> 1 4| 512| 16127.03| 40.80| 394| 0| 31|
> 0| 1612| 0| 15063| 210628| 2234|
> 344124| 0.00| 0.00
> 2 4| 512| 14709.72| 39.94| 367| 0| 31|
> 0| 1612| 0| 17823| 193670| 4457|
> 324744| 0.00| 0.00
> % | 0.0| -8.8| -2.1| -6.9| 0| 0.0|
> 0| 0.0| 0| +18.3| -8.1| +99.5|
> -5.6| 0| 0
> 1 1| 1024| 6436.88| 30.31| 212| 0| 33|
> 0| 1778| 0| 47820| 83940| 2007|
> 172847| 0.00| 0.00
> 2 1| 1024| 6495.48| 30.51| 212| 0| 32|
> 0| 1726| 0| 47771| 85436| 2038|
> 175027| 0.00| 0.00
> % | 0.0| +0.9| +0.7| 0.0| 0| -3.0|
> 0| -2.9| 0| -0.1| +1.8| +1.5|
> +1.3| 0| 0
> 1 2| 1024| 12245.34| 33.44| 365| 0| 31|
> 0| 1629| 0| 26499| 162142| 2909|
> 255717| 0.00| 0.00
> 2 2| 1024| 12913.57| 33.93| 380| 0| 31|
> 0| 1612| 0| 24196| 171386| 3671|
> 266270| 0.00| 0.00
> % | 0.0| +5.5| +1.5| +4.1| 0| 0.0|
> 0| -1.0| 0| -8.7| +5.7| +26.2|
> +4.1| 0| 0
> 1 4| 1024| 16428.48| 34.81| 471| 0| 32|
> 0| 1709| 0| 12496| 215031| 6557|
> 318039| 0.00| 0.00
> 2 4| 1024| 17294.33| 35.05| 492| 0| 32|
> 0| 1709| 0| 9444| 224694| 4095|
> 328098| 0.00| 0.00
> % | 0.0| +5.3| +0.7| +4.5| 0| 0.0|
> 0| 0.0| 0| -24.4| +4.5| -37.5|
> +3.2| 0| 0
> TCP_RR
> sessions| size|throughput| cpu| normalize| #tx-pkts|
> #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr|
> #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
> 1 50| 64| 14626.43| 14.93| 980| 0| 32|
> 0| 1681| 0| 13| 877664| 877731|
> 902624| 0.00| 0.00
> 2 50| 64| 14639.95| 13.10| 1123| 0| 32|
> 0| 1681| 0| 13| 878475| 878538|
> 897278| 0.00| 0.00
> % | 0.0| +0.1| -12.3| +14.6| 0| 0.0|
> 0| 0.0| 0| 0.0| +0.1| +0.1|
> -0.6| 0| 0
> 1 100| 64| 14697.50| 14.31| 1029| 0| 34|
> 0| 1830| 0| 13| 881930| 881991|
> 903837| 0.00| 0.00
> 2 100| 64| 14692.35| 13.08| 1128| 0| 34|
> 0| 1830| 0| 13| 881619| 881679|
> 898952| 0.00| 0.00
> % | 0.0| -0.0| -8.6| +9.6| 0| 0.0|
> 0| 0.0| 0| 0.0| -0.0| -0.0|
> -0.5| 0| 0
> 1 250| 64| 14683.40| 14.34| 1027| 0| 32|
> 0| 1698| 0| 13| 881083| 881147|
> 903071| 0.00| 0.00
> 2 250| 64| 14677.06| 12.85| 1144| 0| 32|
> 0| 1698| 0| 13| 880702| 880762|
> 898190| 0.00| 0.00
> % | 0.0| -0.0| -10.4| +11.4| 0| 0.0|
> 0| 0.0| 0| 0.0| -0.0| -0.0|
> -0.5| 0| 0
> 1 500| 64| 14698.45| 14.39| 1025| 0| 34|
> 0| 1830| 0| 13| 881985| 882060|
> 905537| 0.00| 0.00
> 2 500| 64| 14626.17| 13.54| 1083| 0| 34|
> 0| 1830| 0| 13| 877648| 877726|
> 896427| 0.00| 0.00
> % | 0.0| -0.5| -5.9| +5.7| 0| 0.0|
> 0| 0.0| 0| 0.0| -0.5| -0.5|
> -1.0| 0| 0
> 1 50| 256| 14386.52| 14.14| 1018| 0| 33|
> 0| 1716| 0| 13| 863266| 863336|
> 887195| 0.00| 0.00
> 2 50| 256| 14359.26| 14.22| 1016| 0| 32|
> 0| 1681| 0| 13| 861630| 861698|
> 882444| 0.00| 0.00
> % | 0.0| -0.2| +0.6| -0.2| 0| -3.0|
> 0| -2.0| 0| 0.0| -0.2| -0.2|
> -0.5| 0| 0
> 1 100| 256| 14364.89| 14.25| 1008| 0| 34|
> 0| 1813| 0| 13| 861969| 862033|
> 886679| 0.00| 0.00
> 2 100| 256| 14393.82| 14.53| 999| 0| 34|
> 0| 1813| 0| 13| 863704| 863765|
> 884487| 0.00| 0.00
> % | 0.0| +0.2| +2.0| -0.9| 0| 0.0|
> 0| 0.0| 0| 0.0| +0.2| +0.2|
> -0.2| 0| 0
> 1 250| 256| 14387.95| 14.05| 1024| 0| 32|
> 0| 1681| 0| 13| 863352| 863429|
> 887505| 0.00| 0.00
> 2 250| 256| 14344.74| 14.62| 987| 0| 32|
> 0| 1698| 0| 13| 860760| 860843|
> 882154| 0.00| 0.00
> % | 0.0| -0.3| +4.1| -3.6| 0| 0.0|
> 0| +1.0| 0| 0.0| -0.3| -0.3|
> -0.6| 0| 0
> 1 500| 256| 14365.89| 14.19| 1013| 0| 33|
> 0| 1769| 0| 13| 862029| 862099|
> 885852| 0.00| 0.00
> 2 500| 256| 14329.59| 14.62| 990| 0| 34|
> 0| 1830| 0| 13| 859852| 861233|
> 880082| 0.00| 0.00
> % | 0.0| -0.3| +3.0| -2.3| 0| +3.0|
> 0| +3.4| 0| 0.0| -0.3| -0.1|
> -0.7| 0| 0
> 1 50| 512| 14273.07| 14.12| 1010| 0| 33|
> 0| 1742| 0| 13| 856460| 856524|
> 880356| 0.00| 0.00
> 2 50| 512| 14222.08| 14.72| 966| 0| 32|
> 0| 1698| 0| 12| 853398| 853468|
> 875621| 0.00| 0.00
> % | 0.0| -0.4| +4.2| -4.4| 0| -3.0|
> 0| -2.5| 0| -7.7| -0.4| -0.4|
> -0.5| 0| 0
> 1 100| 512| 14236.34| 14.51| 982| 0| 34|
> 0| 1804| 0| 13| 854258| 854335|
> 876662| 0.00| 0.00
> 2 100| 512| 14147.89| 14.85| 953| 0| 34|
> 0| 1813| 0| 13| 848947| 849031|
> 871773| 0.00| 0.00
> % | 0.0| -0.6| +2.3| -3.0| 0| 0.0|
> 0| +0.5| 0| 0.0| -0.6| -0.6|
> -0.6| 0| 0
> 1 250| 512| 14260.79| 14.53| 983| 0| 33|
> 0| 1760| 0| 13| 855721| 855791|
> 879099| 0.00| 0.00
> 2 250| 512| 14190.68| 14.87| 954| 0| 32|
> 0| 1698| 0| 13| 851517| 851580|
> 874119| 0.00| 0.00
> % | 0.0| -0.5| +2.3| -3.0| 0| -3.0|
> 0| -3.5| 0| 0.0| -0.5| -0.5|
> -0.6| 0| 0
> 1 500| 512| 14273.71| 14.18| 1008| 0| 33|
> 0| 1769| 0| 13| 856499| 856562|
> 879984| 0.00| 0.00
> 2 500| 512| 14213.87| 14.72| 967| 0| 34|
> 0| 1830| 0| 13| 852907| 852976|
> 875328| 0.00| 0.00
> % | 0.0| -0.4| +3.8| -4.1| 0| +3.0|
> 0| +3.4| 0| 0.0| -0.4| -0.4|
> -0.5| 0| 0
> 1 50| 1024| 14049.77| 13.89| 1024| 0| 32|
> 0| 1708| 0| 12| 843061| 843134|
> 863697| 0.00| 0.00
> 2 50| 1024| 13980.25| 14.38| 980| 0| 32|
> 0| 1698| 0| 12| 838890| 838973|
> 858350| 0.00| 0.00
> % | 0.0| -0.5| +3.5| -4.3| 0| 0.0|
> 0| -0.6| 0| 0.0| -0.5| -0.5|
> -0.6| 0| 0
> 1 100| 1024| 14025.66| 13.32| 1066| 0| 33|
> 0| 1769| 0| 13| 841616| 841685|
> 864460| 0.00| 0.00
> 2 100| 1024| 13993.30| 14.82| 946| 0| 34|
> 0| 1830| 0| 12| 839676| 839735|
> 859288| 0.00| 0.00
> % | 0.0| -0.2| +11.3| -11.3| 0| +3.0|
> 0| +3.4| 0| -7.7| -0.2| -0.2|
> -0.6| 0| 0
> 1 250| 1024| 14060.15| 13.90| 1023| 0| 35|
> 0| 1848| 0| 12| 843688| 843752|
> 864475| 0.00| 0.00
> 2 250| 1024| 13982.47| 15.34| 913| 0| 34|
> 0| 1830| 0| 12| 839026| 839089|
> 859914| 0.00| 0.00
> % | 0.0| -0.6| +10.4| -10.8| 0| -2.9|
> 0| -1.0| 0| 0.0| -0.6| -0.6|
> -0.5| 0| 0
> 1 500| 1024| 14051.14| 13.80| 1024| 0| 33|
> 0| 1716| 0| 13| 843144| 843212|
> 862981| 0.00| 0.00
> 2 500| 1024| 14013.95| 15.27| 918| 0| 32|
> 0| 1681| 0| 13| 840915| 840983|
> 862635| 0.00| 0.00
> % | 0.0| -0.3| +10.7| -10.4| 0| -3.0|
> 0| -2.0| 0| 0.0| -0.3| -0.3|
> -0.0| 0| 0
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Amos Kong @ 2011-12-19 2:50 UTC (permalink / raw)
To: Rusty Russell
Cc: kvm, Michael S. Tsirkin, Benjamin Herrenschmidt, linux-kernel,
virtualization, rhod, linux-arm-kernel
In-Reply-To: <4EEE9F16.8000501@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3122 bytes --]
On 19/12/11 10:19, Amos Kong wrote:
> On 12/12/11 13:12, Rusty Russell wrote:
>> On Mon, 12 Dec 2011 11:06:53 +0800, Amos Kong<akong@redhat.com> wrote:
>>> On 12/12/11 06:27, Benjamin Herrenschmidt wrote:
>>>> On Sun, 2011-12-11 at 14:25 +0200, Michael S. Tsirkin wrote:
>>>>
>>>>> Forwarding some results by Amos, who run multiple netperf streams in
>>>>> parallel, from an external box to the guest. TCP_STREAM results were
>>>>> noisy. This could be due to buffering done by TCP, where packet size
>>>>> varies even as message size is constant.
>>>>>
>>>>> TCP_RR results were consistent. In this benchmark, after switching
>>>>> to mandatory barriers, CPU utilization increased by up to 35% while
>>>>> throughput went down by up to 14%. the normalized throughput/cpu
>>>>> regressed consistently, between 7 and 35%
>>>>>
>>>>> The "fix" applied was simply this:
>>>>
>>>> What machine& processor was this ?
>>>
>>> pined guest memory to numa node 1
>>
>> Please try this patch. How much does the branch cost us?
>>
>> (Compiles, untested).
>>
>> Thanks,
>> Rusty.
>>
>> From: Rusty Russell<rusty@rustcorp.com.au>
>> Subject: virtio: harsher barriers for virtio-mmio.
>>
>> We were cheating with our barriers; using the smp ones rather than the
>> real device ones. That was fine, until virtio-mmio came along, which
>> could be talking to a real device (a non-SMP CPU).
>>
>> Unfortunately, just putting back the real barriers (reverting
>> d57ed95d) causes a performance regression on virtio-pci. In
>> particular, Amos reports netbench's TCP_RR over virtio_net CPU
>> utilization increased up to 35% while throughput went down by up to
>> 14%.
>>
>> By comparison, this branch costs us???
>>
>> Reference: https://lkml.org/lkml/2011/12/11/22
>>
>> Signed-off-by: Rusty Russell<rusty@rustcorp.com.au>
>> ---
>> drivers/lguest/lguest_device.c | 10 ++++++----
>> drivers/s390/kvm/kvm_virtio.c | 2 +-
>> drivers/virtio/virtio_mmio.c | 7 ++++---
>> drivers/virtio/virtio_pci.c | 4 ++--
>> drivers/virtio/virtio_ring.c | 34 +++++++++++++++++++++-------------
>> include/linux/virtio_ring.h | 1 +
>> tools/virtio/linux/virtio.h | 1 +
>> tools/virtio/virtio_test.c | 3 ++-
>> 8 files changed, 38 insertions(+), 24 deletions(-)
>
> Hi all,
>
> I tested with the same environment and scenarios.
> tested one scenarios for three times and compute the average for more
> precision.
>
> Thanks, Amos
>
> --------- compare results -----------
> Mon Dec 19 09:51:09 2011
>
> 1 - avg-old.netperf.exhost_guest.txt
> 2 - avg-fixed.netperf.exhost_guest.txt
>
> ======
> TCP_STREAM
> sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts|
> #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit|
> #rpkt/#irq
> 1 1| 64| 1073.54| 10.50| 102| 0| 31| 0| 1612| 0| 16| 487641| 489753|
> 504764| 0.00| 0.00
> 2 1| 64| 1079.44| 10.29| 104| 0| 30| 0| 1594| 0| 17| 487156| 488828|
> 504411| 0.00| 0.00
> % | 0.0| +0.5| -2.0| +2.0| 0| -3.2| 0| -1.1| 0| +6.2| -0.1| -0.2| -0.1|
The format is broken in webpage, attached the result file.
it's also available here: http://amosk.info/download/rusty-fix-perf.txt
[-- Attachment #2: rusty-fix-perf.txt --]
[-- Type: text/plain, Size: 42872 bytes --]
--------- compare results -----------
Mon Dec 19 09:51:09 2011
1 - avg-old.netperf.exhost_guest.txt
2 - avg-fixed.netperf.exhost_guest.txt
======
TCP_STREAM
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 1073.54| 10.50| 102| 0| 31| 0| 1612| 0| 16| 487641| 489753| 504764| 0.00| 0.00
2 1| 64| 1079.44| 10.29| 104| 0| 30| 0| 1594| 0| 17| 487156| 488828| 504411| 0.00| 0.00
% | 0.0| +0.5| -2.0| +2.0| 0| -3.2| 0| -1.1| 0| +6.2| -0.1| -0.2| -0.1| 0| 0
1 2| 64| 2141.12| 15.72| 136| 0| 33| 0| 1744| 0| 34| 873777| 972303| 928926| 0.00| 0.00
2 2| 64| 2140.88| 15.64| 137| 0| 33| 0| 1744| 0| 34| 926588| 942841| 974095| 0.00| 0.00
% | 0.0| -0.0| -0.5| +0.7| 0| 0.0| 0| 0.0| 0| 0.0| +6.0| -3.0| +4.9| 0| 0
1 4| 64| 4076.80| 19.82| 205| 0| 30| 0| 1577| 0| 67| 1422282| 1166425| 1539219| 0.00| 0.00
2 4| 64| 4094.32| 20.70| 197| 0| 31| 0| 1612| 0| 68| 1704330| 1314077| 1833394| 0.00| 0.00
% | 0.0| +0.4| +4.4| -3.9| 0| +3.3| 0| +2.2| 0| +1.5| +19.8| +12.7| +19.1| 0| 0
1 1| 256| 2867.48| 13.44| 213| 0| 32| 0| 1726| 0| 14| 666430| 694922| 690730| 0.00| 0.00
2 1| 256| 2874.20| 12.71| 226| 0| 32| 0| 1709| 0| 14| 697960| 740407| 721807| 0.00| 0.00
% | 0.0| +0.2| -5.4| +6.1| 0| 0.0| 0| -1.0| 0| 0.0| +4.7| +6.5| +4.5| 0| 0
1 2| 256| 5642.82| 17.61| 320| 0| 30| 0| 1594| 0| 30| 1226861| 1236081| 1268562| 0.00| 0.00
2 2| 256| 5661.06| 17.41| 326| 0| 30| 0| 1594| 0| 29| 1175696| 1143490| 1221528| 0.00| 0.00
% | 0.0| +0.3| -1.1| +1.9| 0| 0.0| 0| 0.0| 0| -3.3| -4.2| -7.5| -3.7| 0| 0
1 4| 256| 9404.27| 23.55| 399| 0| 33| 0| 1744| 0| 37| 1692245| 659975| 1765103| 0.00| 0.00
2 4| 256| 8761.11| 23.18| 376| 0| 32| 0| 1726| 0| 36| 1699382| 418992| 1870804| 0.00| 0.00
% | 0.0| -6.8| -1.6| -5.8| 0| -3.0| 0| -1.0| 0| -2.7| +0.4| -36.5| +6.0| 0| 0
1 1| 512| 3803.66| 14.20| 267| 0| 30| 0| 1594| 0| 14| 693992| 750078| 721107| 0.00| 0.00
2 1| 512| 3838.02| 15.47| 248| 0| 31| 0| 1612| 0| 15| 811709| 773505| 838788| 0.00| 0.00
% | 0.0| +0.9| +8.9| -7.1| 0| +3.3| 0| +1.1| 0| +7.1| +17.0| +3.1| +16.3| 0| 0
1 2| 512| 8606.11| 19.34| 444| 0| 32| 0| 1709| 0| 29| 1264624| 647652| 1309740| 0.00| 0.00
2 2| 512| 8127.80| 18.93| 428| 0| 32| 0| 1726| 0| 28| 1216606| 1179269| 1266260| 0.00| 0.00
% | 0.0| -5.6| -2.1| -3.6| 0| 0.0| 0| +1.0| 0| -3.4| -3.8| +82.1| -3.3| 0| 0
1 4| 512| 9409.41| 22.88| 413| 0| 30| 0| 1577| 0| 35| 1592587| 1072862| 1746787| 0.00| 0.00
2 4| 512| 9217.34| 23.05| 400| 0| 30| 0| 1594| 0| 34| 1596515| 513742| 1831538| 0.00| 0.00
% | 0.0| -2.0| +0.7| -3.1| 0| 0.0| 0| +1.1| 0| -2.9| +0.2| -52.1| +4.9| 0| 0
1 1| 1024| 4389.75| 14.62| 303| 0| 32| 0| 1726| 0| 14| 663417| 611555| 689028| 0.00| 0.00
2 1| 1024| 4390.44| 13.66| 321| 0| 32| 0| 1726| 0| 13| 609836| 556090| 634511| 0.00| 0.00
% | 0.0| +0.0| -6.6| +5.9| 0| 0.0| 0| 0.0| 0| -7.1| -8.1| -9.1| -7.9| 0| 0
1 2| 1024| 9046.18| 19.63| 460| 0| 30| 0| 1594| 0| 28| 1206853| 1054653| 1256203| 0.00| 0.00
2 2| 1024| 9027.54| 20.15| 447| 0| 30| 0| 1577| 0| 27| 1179555| 884408| 1226843| 0.00| 0.00
% | 0.0| -0.2| +2.6| -2.8| 0| 0.0| 0| -1.1| 0| -3.6| -2.3| -16.1| -2.3| 0| 0
1 4| 1024| 9410.41| 22.01| 427| 0| 32| 0| 1726| 0| 36| 1734433| 887190| 1852486| 0.00| 0.00
2 4| 1024| 9409.11| 23.18| 405| 0| 32| 0| 1726| 0| 34| 1695359| 625268| 1803599| 0.00| 0.00
% | 0.0| -0.0| +5.3| -5.2| 0| 0.0| 0| 0.0| 0| -5.6| -2.3| -29.5| -2.6| 0| 0
TCP_MAERTS
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 1056.13| 17.51| 59| 0| 30| 0| 1594| 3| 86| 476098| 4780186| 538158| 0.00| 0.00
2 1| 64| 1065.51| 17.64| 60| 0| 30| 0| 1594| 3| 87| 476836| 4823602| 538860| 0.00| 0.00
% | 0.0| +0.9| +0.7| +1.7| 0| 0.0| 0| 0.0| 0.0| +1.2| +0.2| +0.9| +0.1| 0| 0
1 2| 64| 2472.80| 32.18| 76| 0| 32| 0| 1709| 2| 199| 479119| 2089931| 600119| 0.00| 0.00
2 2| 64| 2468.76| 32.28| 76| 0| 33| 0| 1744| 1| 199| 479372| 2179342| 600328| 0.00| 0.00
% | 0.0| -0.2| +0.3| 0.0| 0| +3.1| 0| +2.0| -50.0| 0.0| +0.1| +4.3| +0.0| 0| 0
1 4| 64| 2453.22| 32.20| 75| 0| 31| 0| 1612| 2| 198| 479223| 2175801| 600081| 0.00| 0.00
2 4| 64| 2465.68| 32.30| 76| 0| 30| 0| 1594| 3| 200| 479404| 2108293| 600252| 0.00| 0.00
% | 0.0| +0.5| +0.3| +1.3| 0| -3.2| 0| -1.1| +50.0| +1.0| +0.0| -3.1| +0.0| 0| 0
1 1| 256| 3608.37| 24.59| 146| 0| 32| 0| 1726| 2| 277| 88346| 108310| 150637| 0.00| 0.00
2 1| 256| 3611.12| 24.95| 144| 0| 32| 0| 1709| 0| 281| 83319| 64354| 145511| 0.00| 0.00
% | 0.0| +0.1| +1.5| -1.4| 0| 0.0| 0| -1.0| -100.0| +1.4| -5.7| -40.6| -3.4| 0| 0
1 2| 256| 7373.32| 26.83| 274| 0| 31| 0| 1612| 0| 4185| 278932| 264031| 377267| 0.00| 0.00
2 2| 256| 7460.03| 26.93| 276| 0| 30| 0| 1594| 1| 5913| 270840| 246165| 371999| 0.00| 0.00
% | 0.0| +1.2| +0.4| +0.7| 0| -3.2| 0| -1.1| 0| +41.3| -2.9| -6.8| -1.4| 0| 0
1 4| 256| 9322.66| 29.73| 313| 0| 32| 0| 1709| 848| 3041| 363114| 329308| 482586| 0.00| 0.00
2 4| 256| 9365.52| 29.59| 316| 0| 33| 0| 1744| 414| 2884| 371485| 339191| 491366| 0.00| 0.00
% | 0.0| +0.5| -0.5| +1.0| 0| +3.1| 0| +2.0| -51.2| -5.2| +2.3| +3.0| +1.8| 0| 0
1 1| 512| 9360.25| 17.20| 543| 0| 30| 0| 1577| 0| 387| 438621| 408062| 499989| 0.00| 0.00
2 1| 512| 8899.37| 18.17| 495| 0| 30| 0| 1594| 0| 5049| 393341| 371545| 459397| 0.00| 0.00
% | 0.0| -4.9| +5.6| -8.8| 0| 0.0| 0| +1.1| 0| +1204.7| -10.3| -8.9| -8.1| 0| 0
1 2| 512| 8713.11| 20.77| 420| 0| 32| 0| 1726| 0| 11227| 296157| 246495| 371632| 0.00| 0.00
2 2| 512| 8686.31| 20.72| 421| 0| 32| 0| 1709| 0| 11002| 296608| 246597| 371797| 0.00| 0.00
% | 0.0| -0.3| -0.2| +0.2| 0| 0.0| 0| -1.0| 0| -2.0| +0.2| +0.0| +0.0| 0| 0
1 4| 512| 8780.40| 22.72| 386| 0| 30| 0| 1594| 0| 10337| 303619| 249822| 385457| 0.00| 0.00
2 4| 512| 8858.51| 22.66| 390| 0| 30| 0| 1577| 0| 9968| 301847| 246543| 382121| 0.00| 0.00
% | 0.0| +0.9| -0.3| +1.0| 0| 0.0| 0| -1.1| 0| -3.6| -0.6| -1.3| -0.9| 0| 0
1 1| 1024| 9387.09| 16.43| 571| 0| 32| 0| 1726| 0| 84| 452351| 429483| 504022| 0.00| 0.00
2 1| 1024| 9388.90| 16.51| 568| 0| 32| 0| 1726| 2| 76| 446994| 422489| 499025| 0.00| 0.00
% | 0.0| +0.0| +0.5| -0.5| 0| 0.0| 0| 0.0| 0| -9.5| -1.2| -1.6| -1.0| 0| 0
1 2| 1024| 9361.43| 17.26| 542| 0| 30| 0| 1594| 5| 647| 388626| 358303| 442125| 0.00| 0.00
2 2| 1024| 9364.78| 17.25| 542| 0| 31| 0| 1612| 35| 554| 389326| 360169| 442343| 0.00| 0.00
% | 0.0| +0.0| -0.1| 0.0| 0| +3.3| 0| +1.1| +600.0| -14.4| +0.2| +0.5| +0.0| 0| 0
1 4| 1024| 9381.57| 18.35| 510| 0| 32| 0| 1726| 1189| 648| 405900| 376269| 459845| 0.00| 0.00
2 4| 1024| 9393.48| 18.27| 513| 0| 32| 0| 1726| 1754| 610| 402132| 373768| 455629| 0.00| 0.00
% | 0.0| +0.1| -0.4| +0.6| 0| 0.0| 0| 0.0| +47.5| -5.9| -0.9| -0.7| -0.9| 0| 0
TCP_RR
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 50| 64| 10903.70| 8.03| 1382| 0| 32| 0| 1698| 0| 9| 654298| 654362| 665532| 0.00| 0.00
2 50| 64| 10880.50| 7.40| 1488| 0| 32| 0| 1698| 0| 10| 652907| 652973| 667042| 0.00| 0.00
% | 0.0| -0.2| -7.8| +7.7| 0| 0.0| 0| 0.0| 0| +11.1| -0.2| -0.2| +0.2| 0| 0
1 100| 64| 10953.00| 8.40| 1332| 0| 34| 0| 1830| 0| 10| 657257| 657325| 667088| 0.00| 0.00
2 100| 64| 10882.78| 7.67| 1439| 0| 34| 0| 1830| 0| 9| 653044| 653110| 668883| 0.00| 0.00
% | 0.0| -0.6| -8.7| +8.0| 0| 0.0| 0| 0.0| 0| -10.0| -0.6| -0.6| +0.3| 0| 0
1 250| 64| 10902.66| 8.57| 1300| 0| 33| 0| 1716| 0| 10| 654235| 654308| 665518| 0.00| 0.00
2 250| 64| 10866.79| 7.58| 1449| 0| 32| 0| 1664| 0| 10| 652083| 652155| 666869| 0.00| 0.00
% | 0.0| -0.3| -11.6| +11.5| 0| -3.0| 0| -3.0| 0| 0.0| -0.3| -0.3| +0.2| 0| 0
1 500| 64| 10924.34| 7.25| 1509| 0| 34| 0| 1830| 0| 10| 655536| 655619| 665776| 0.00| 0.00
2 500| 64| 10927.52| 6.50| 1684| 0| 34| 0| 1813| 0| 10| 655726| 655803| 668527| 0.00| 0.00
% | 0.0| +0.0| -10.3| +11.6| 0| 0.0| 0| -0.9| 0| 0.0| +0.0| +0.0| +0.4| 0| 0
1 50| 256| 10407.35| 9.38| 1112| 0| 32| 0| 1681| 0| 9| 624516| 624581| 639159| 0.00| 0.00
2 50| 256| 10422.60| 9.45| 1108| 0| 33| 0| 1716| 0| 9| 625432| 625498| 641343| 0.00| 0.00
% | 0.0| +0.1| +0.7| -0.4| 0| +3.1| 0| +2.1| 0| 0.0| +0.1| +0.1| +0.3| 0| 0
1 100| 256| 10404.30| 8.99| 1159| 0| 34| 0| 1830| 0| 9| 624335| 624400| 637357| 0.00| 0.00
2 100| 256| 10442.84| 9.57| 1093| 0| 35| 0| 1848| 0| 9| 626650| 626714| 639017| 0.00| 0.00
% | 0.0| +0.4| +6.5| -5.7| 0| +2.9| 0| +1.0| 0| 0.0| +0.4| +0.4| +0.3| 0| 0
1 250| 256| 10427.71| 9.10| 1157| 0| 32| 0| 1698| 0| 9| 625738| 625822| 641221| 0.00| 0.00
2 250| 256| 10464.71| 9.69| 1085| 0| 32| 0| 1698| 0| 9| 627960| 628040| 640680| 0.00| 0.00
% | 0.0| +0.4| +6.5| -6.2| 0| 0.0| 0| 0.0| 0| 0.0| +0.4| +0.4| -0.1| 0| 0
1 500| 256| 10442.18| 8.65| 1217| 0| 34| 0| 1830| 0| 10| 626608| 626675| 640081| 0.00| 0.00
2 500| 256| 10463.74| 9.63| 1089| 0| 34| 0| 1813| 0| 9| 627904| 627967| 643152| 0.00| 0.00
% | 0.0| +0.2| +11.3| -10.5| 0| 0.0| 0| -0.9| 0| -10.0| +0.2| +0.2| +0.5| 0| 0
1 50| 512| 8505.70| 7.20| 1191| 0| 33| 0| 1716| 0| 7| 510418| 510486| 524904| 0.00| 0.00
2 50| 512| 8563.34| 7.24| 1185| 0| 32| 0| 1664| 0| 8| 513877| 513940| 526294| 0.00| 0.00
% | 0.0| +0.7| +0.6| -0.5| 0| -3.0| 0| -3.0| 0| +14.3| +0.7| +0.7| +0.3| 0| 0
1 100| 512| 8509.97| 7.00| 1226| 0| 34| 0| 1830| 0| 7| 510674| 510756| 525205| 0.00| 0.00
2 100| 512| 8555.22| 7.52| 1144| 0| 34| 0| 1830| 0| 7| 513389| 513471| 526609| 0.00| 0.00
% | 0.0| +0.5| +7.4| -6.7| 0| 0.0| 0| 0.0| 0| 0.0| +0.5| +0.5| +0.3| 0| 0
1 250| 512| 8507.35| 7.21| 1183| 0| 32| 0| 1681| 0| 7| 510518| 510579| 524294| 0.00| 0.00
2 250| 512| 8578.13| 7.01| 1223| 0| 33| 0| 1716| 0| 8| 514765| 514829| 526481| 0.00| 0.00
% | 0.0| +0.8| -2.8| +3.4| 0| +3.1| 0| +2.1| 0| +14.3| +0.8| +0.8| +0.4| 0| 0
1 500| 512| 8521.68| 6.54| 1302| 0| 34| 0| 1813| 0| 8| 511375| 511443| 523357| 0.00| 0.00
2 500| 512| 8573.17| 6.94| 1235| 0| 34| 0| 1830| 0| 7| 514467| 514533| 526131| 0.00| 0.00
% | 0.0| +0.6| +6.1| -5.1| 0| 0.0| 0| +0.9| 0| -12.5| +0.6| +0.6| +0.5| 0| 0
1 50| 1024| 8150.01| 7.69| 1060| 0| 32| 0| 1681| 0| 7| 489075| 489155| 503136| 0.00| 0.00
2 50| 1024| 8129.35| 7.65| 1062| 0| 34| 0| 1804| 0| 7| 487841| 487915| 502061| 0.00| 0.00
% | 0.0| -0.3| -0.5| +0.2| 0| +6.2| 0| +7.3| 0| 0.0| -0.3| -0.3| -0.2| 0| 0
1 100| 1024| 8166.06| 7.53| 1083| 0| 34| 0| 1804| 0| 7| 490039| 490104| 502990| 0.00| 0.00
2 100| 1024| 8118.23| 7.77| 1044| 0| 33| 0| 1725| 0| 7| 487171| 487236| 501939| 0.00| 0.00
% | 0.0| -0.6| +3.2| -3.6| 0| -2.9| 0| -4.4| 0| 0.0| -0.6| -0.6| -0.2| 0| 0
1 250| 1024| 8175.35| 7.58| 1079| 0| 35| 0| 1848| 0| 7| 490597| 490657| 503641| 0.00| 0.00
2 250| 1024| 8146.63| 7.59| 1072| 0| 34| 0| 1813| 0| 7| 488874| 488939| 502010| 0.00| 0.00
% | 0.0| -0.4| +0.1| -0.6| 0| -2.9| 0| -1.9| 0| 0.0| -0.4| -0.4| -0.3| 0| 0
1 500| 1024| 8182.51| 7.61| 1075| 0| 32| 0| 1698| 0| 7| 491028| 491095| 504222| 0.00| 0.00
2 500| 1024| 8157.39| 7.58| 1075| 0| 33| 0| 1716| 0| 7| 489521| 489593| 502368| 0.00| 0.00
% | 0.0| -0.3| -0.4| 0.0| 0| +3.1| 0| +1.1| 0| 0.0| -0.3| -0.3| -0.4| 0| 0
Mon Dec 19 09:51:09 2011
1 - avg-old.netperf.host_guest.txt
2 - avg-fixed.netperf.host_guest.txt
======
TCP_STREAM
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 715.76| 28.44| 24| 0| 31| 0| 1629| 0| 36| 3206862| 1733540| 3245171| 0.00| 0.00
2 1| 64| 714.82| 28.44| 25| 0| 31| 0| 1612| 0| 36| 3204256| 1709508| 3242450| 0.00| 0.00
% | 0.0| -0.1| 0.0| +4.2| 0| 0.0| 0| -1.0| 0| 0.0| -0.1| -1.4| -0.1| 0| 0
1 2| 64| 1449.31| 41.23| 35| 0| 33| 0| 1744| 0| 66| 2764635| 1667527| 2815591| 0.00| 0.00
2 2| 64| 1442.92| 41.32| 34| 0| 32| 0| 1709| 0| 66| 2751461| 1659498| 2799277| 0.00| 0.00
% | 0.0| -0.4| +0.2| -2.9| 0| -3.0| 0| -2.0| 0| 0.0| -0.5| -0.5| -0.6| 0| 0
1 4| 64| 2671.25| 48.95| 54| 0| 30| 0| 1577| 0| 47| 914085| 289771| 947054| 0.00| 0.00
2 4| 64| 2652.68| 48.20| 54| 0| 30| 0| 1594| 0| 46| 882300| 293273| 914249| 0.00| 0.00
% | 0.0| -0.7| -1.5| 0.0| 0| 0.0| 0| +1.1| 0| -2.1| -3.5| +1.2| -3.5| 0| 0
1 1| 256| 1478.61| 29.34| 50| 0| 32| 0| 1709| 0| 64| 3502384| 1541681| 3545371| 0.00| 0.00
2 1| 256| 1481.38| 29.27| 50| 0| 32| 0| 1726| 0| 64| 3485623| 1526105| 3528343| 0.00| 0.00
% | 0.0| +0.2| -0.2| 0.0| 0| 0.0| 0| +1.0| 0| 0.0| -0.5| -1.0| -0.5| 0| 0
1 2| 256| 3095.93| 42.31| 72| 0| 31| 0| 1612| 0| 123| 1521019| 466426| 1637722| 0.00| 0.00
2 2| 256| 3098.16| 42.03| 73| 0| 30| 0| 1594| 0| 123| 1519458| 472632| 1632462| 0.00| 0.00
% | 0.0| +0.1| -0.7| +1.4| 0| -3.2| 0| -1.1| 0| 0.0| -0.1| +1.3| -0.3| 0| 0
1 4| 256| 6553.60| 38.44| 170| 0| 33| 0| 1761| 0| 38| 1343193| 237604| 1402385| 0.00| 0.00
2 4| 256| 6649.37| 38.34| 172| 0| 32| 0| 1726| 0| 32| 1343770| 236320| 1400875| 0.00| 0.00
% | 0.0| +1.5| -0.3| +1.2| 0| -3.0| 0| -2.0| 0| -15.8| +0.0| -0.5| -0.1| 0| 0
1 1| 512| 1818.40| 29.28| 61| 0| 31| 0| 1646| 0| 76| 3326887| 1491961| 3371189| 0.00| 0.00
2 1| 512| 1822.74| 29.45| 61| 0| 30| 0| 1577| 0| 76| 3309934| 1470715| 3352921| 0.00| 0.00
% | 0.0| +0.2| +0.6| 0.0| 0| -3.2| 0| -4.2| 0| 0.0| -0.5| -1.4| -0.5| 0| 0
1 2| 512| 3931.72| 43.51| 89| 0| 33| 0| 1761| 0| 137| 1148331| 301194| 1270351| 0.00| 0.00
2 2| 512| 3926.16| 43.45| 90| 0| 32| 0| 1726| 0| 135| 1166280| 306110| 1288869| 0.00| 0.00
% | 0.0| -0.1| -0.1| +1.1| 0| -3.0| 0| -2.0| 0| -1.5| +1.6| +1.6| +1.5| 0| 0
1 4| 512| 8634.49| 40.69| 211| 0| 31| 0| 1612| 0| 53| 1869998| 353856| 1948593| 0.00| 0.00
2 4| 512| 9137.12| 40.77| 223| 0| 30| 0| 1594| 0| 48| 1879574| 362851| 1959044| 0.00| 0.00
% | 0.0| +5.8| +0.2| +5.7| 0| -3.2| 0| -1.1| 0| -9.4| +0.5| +2.5| +0.5| 0| 0
1 1| 1024| 2042.67| 29.50| 68| 0| 33| 0| 1778| 0| 84| 3087032| 1309160| 3130736| 0.00| 0.00
2 1| 1024| 2033.24| 29.51| 68| 0| 32| 0| 1726| 0| 83| 3082898| 1295936| 3125229| 0.00| 0.00
% | 0.0| -0.5| +0.0| 0.0| 0| -3.0| 0| -2.9| 0| -1.2| -0.1| -1.0| -0.2| 0| 0
1 2| 1024| 7703.26| 39.58| 194| 0| 32| 0| 1673| 0| 65| 2522172| 663302| 2684835| 0.00| 0.00
2 2| 1024| 7657.00| 39.27| 194| 0| 30| 0| 1594| 0| 62| 2607281| 698035| 2755198| 0.00| 0.00
% | 0.0| -0.6| -0.8| 0.0| 0| -6.2| 0| -4.7| 0| -4.6| +3.4| +5.2| +2.6| 0| 0
1 4| 1024| 11814.84| 39.38| 299| 0| 32| 0| 1700| 0| 28| 2510318| 576071| 2596631| 0.00| 0.00
2 4| 1024| 12871.76| 38.93| 330| 0| 32| 0| 1726| 0| 25| 2232437| 632785| 2316035| 0.00| 0.00
% | 0.0| +8.9| -1.1| +10.4| 0| 0.0| 0| +1.5| 0| -10.7| -11.1| +9.8| -10.8| 0| 0
TCP_MAERTS
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 1| 64| 706.98| 26.25| 26| 0| 31| 0| 1656| 0| 80| 2630204| 4185330| 2692397| 0.00| 0.00
2 1| 64| 767.45| 27.78| 27| 0| 30| 0| 1594| 0| 85| 2626694| 4317273| 2688799| 0.00| 0.00
% | 0.0| +8.6| +5.8| +3.8| 0| -3.2| 0| -3.7| 0| +6.2| -0.1| +3.2| -0.1| 0| 0
1 2| 64| 2644.57| 42.60| 61| 0| 32| 0| 1700| 0| 34863| 49057| 16791| 204805| 0.00| 0.00
2 2| 64| 2721.19| 42.69| 63| 0| 32| 0| 1709| 0| 42365| 52739| 20094| 215895| 0.00| 0.00
% | 0.0| +2.9| +0.2| +3.3| 0| 0.0| 0| +0.5| 0| +21.5| +7.5| +19.7| +5.4| 0| 0
1 4| 64| 2756.40| 42.69| 64| 0| 32| 0| 1708| 0| 52043| 47976| 12694| 220732| 0.00| 0.00
2 4| 64| 2709.19| 42.79| 62| 0| 30| 0| 1594| 0| 50144| 47275| 12743| 218074| 0.00| 0.00
% | 0.0| -1.7| +0.2| -3.1| 0| -6.2| 0| -6.7| 0| -3.6| -1.5| +0.4| -1.2| 0| 0
1 1| 256| 3785.63| 32.34| 116| 0| 33| 0| 1734| 0| 36642| 58940| 1187| 157652| 0.00| 0.00
2 1| 256| 3593.17| 32.90| 108| 0| 32| 0| 1726| 0| 33179| 54980| 1130| 150168| 0.00| 0.00
% | 0.0| -5.1| +1.7| -6.9| 0| -3.0| 0| -0.5| 0| -9.5| -6.7| -4.8| -4.7| 0| 0
1 2| 256| 8316.26| 40.45| 205| 0| 32| 0| 1673| 0| 28302| 114835| 1655| 251137| 0.00| 0.00
2 2| 256| 8390.41| 41.17| 203| 0| 30| 0| 1594| 0| 31222| 115372| 1696| 257151| 0.00| 0.00
% | 0.0| +0.9| +1.8| -1.0| 0| -6.2| 0| -4.7| 0| +10.3| +0.5| +2.5| +2.4| 0| 0
1 4| 256| 9672.49| 42.40| 227| 0| 33| 0| 1761| 0| 30045| 132027| 3059| 283491| 0.00| 0.00
2 4| 256| 9741.71| 42.57| 228| 0| 32| 0| 1726| 6| 28875| 132125| 1999| 283036| 0.00| 0.00
% | 0.0| +0.7| +0.4| +0.4| 0| -3.0| 0| -2.0| 0| -3.9| +0.1| -34.7| -0.2| 0| 0
1 1| 512| 6052.41| 32.23| 187| 0| 31| 0| 1612| 0| 44681| 86084| 2592| 187465| 0.00| 0.00
2 1| 512| 6267.37| 32.51| 192| 0| 30| 0| 1577| 0| 45278| 88449| 2708| 191374| 0.00| 0.00
% | 0.0| +3.6| +0.9| +2.7| 0| -3.2| 0| -2.2| 0| +1.3| +2.7| +4.5| +2.1| 0| 0
1 2| 512| 12714.52| 38.27| 331| 0| 33| 0| 1744| 0| 24843| 169170| 2381| 292210| 0.00| 0.00
2 2| 512| 11341.65| 37.30| 303| 0| 32| 0| 1726| 14| 27393| 152465| 2980| 270740| 0.00| 0.00
% | 0.0| -10.8| -2.5| -8.5| 0| -3.0| 0| -1.0| 0| +10.3| -9.9| +25.2| -7.3| 0| 0
1 4| 512| 16127.03| 40.80| 394| 0| 31| 0| 1612| 0| 15063| 210628| 2234| 344124| 0.00| 0.00
2 4| 512| 14709.72| 39.94| 367| 0| 31| 0| 1612| 0| 17823| 193670| 4457| 324744| 0.00| 0.00
% | 0.0| -8.8| -2.1| -6.9| 0| 0.0| 0| 0.0| 0| +18.3| -8.1| +99.5| -5.6| 0| 0
1 1| 1024| 6436.88| 30.31| 212| 0| 33| 0| 1778| 0| 47820| 83940| 2007| 172847| 0.00| 0.00
2 1| 1024| 6495.48| 30.51| 212| 0| 32| 0| 1726| 0| 47771| 85436| 2038| 175027| 0.00| 0.00
% | 0.0| +0.9| +0.7| 0.0| 0| -3.0| 0| -2.9| 0| -0.1| +1.8| +1.5| +1.3| 0| 0
1 2| 1024| 12245.34| 33.44| 365| 0| 31| 0| 1629| 0| 26499| 162142| 2909| 255717| 0.00| 0.00
2 2| 1024| 12913.57| 33.93| 380| 0| 31| 0| 1612| 0| 24196| 171386| 3671| 266270| 0.00| 0.00
% | 0.0| +5.5| +1.5| +4.1| 0| 0.0| 0| -1.0| 0| -8.7| +5.7| +26.2| +4.1| 0| 0
1 4| 1024| 16428.48| 34.81| 471| 0| 32| 0| 1709| 0| 12496| 215031| 6557| 318039| 0.00| 0.00
2 4| 1024| 17294.33| 35.05| 492| 0| 32| 0| 1709| 0| 9444| 224694| 4095| 328098| 0.00| 0.00
% | 0.0| +5.3| +0.7| +4.5| 0| 0.0| 0| 0.0| 0| -24.4| +4.5| -37.5| +3.2| 0| 0
TCP_RR
sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
1 50| 64| 14626.43| 14.93| 980| 0| 32| 0| 1681| 0| 13| 877664| 877731| 902624| 0.00| 0.00
2 50| 64| 14639.95| 13.10| 1123| 0| 32| 0| 1681| 0| 13| 878475| 878538| 897278| 0.00| 0.00
% | 0.0| +0.1| -12.3| +14.6| 0| 0.0| 0| 0.0| 0| 0.0| +0.1| +0.1| -0.6| 0| 0
1 100| 64| 14697.50| 14.31| 1029| 0| 34| 0| 1830| 0| 13| 881930| 881991| 903837| 0.00| 0.00
2 100| 64| 14692.35| 13.08| 1128| 0| 34| 0| 1830| 0| 13| 881619| 881679| 898952| 0.00| 0.00
% | 0.0| -0.0| -8.6| +9.6| 0| 0.0| 0| 0.0| 0| 0.0| -0.0| -0.0| -0.5| 0| 0
1 250| 64| 14683.40| 14.34| 1027| 0| 32| 0| 1698| 0| 13| 881083| 881147| 903071| 0.00| 0.00
2 250| 64| 14677.06| 12.85| 1144| 0| 32| 0| 1698| 0| 13| 880702| 880762| 898190| 0.00| 0.00
% | 0.0| -0.0| -10.4| +11.4| 0| 0.0| 0| 0.0| 0| 0.0| -0.0| -0.0| -0.5| 0| 0
1 500| 64| 14698.45| 14.39| 1025| 0| 34| 0| 1830| 0| 13| 881985| 882060| 905537| 0.00| 0.00
2 500| 64| 14626.17| 13.54| 1083| 0| 34| 0| 1830| 0| 13| 877648| 877726| 896427| 0.00| 0.00
% | 0.0| -0.5| -5.9| +5.7| 0| 0.0| 0| 0.0| 0| 0.0| -0.5| -0.5| -1.0| 0| 0
1 50| 256| 14386.52| 14.14| 1018| 0| 33| 0| 1716| 0| 13| 863266| 863336| 887195| 0.00| 0.00
2 50| 256| 14359.26| 14.22| 1016| 0| 32| 0| 1681| 0| 13| 861630| 861698| 882444| 0.00| 0.00
% | 0.0| -0.2| +0.6| -0.2| 0| -3.0| 0| -2.0| 0| 0.0| -0.2| -0.2| -0.5| 0| 0
1 100| 256| 14364.89| 14.25| 1008| 0| 34| 0| 1813| 0| 13| 861969| 862033| 886679| 0.00| 0.00
2 100| 256| 14393.82| 14.53| 999| 0| 34| 0| 1813| 0| 13| 863704| 863765| 884487| 0.00| 0.00
% | 0.0| +0.2| +2.0| -0.9| 0| 0.0| 0| 0.0| 0| 0.0| +0.2| +0.2| -0.2| 0| 0
1 250| 256| 14387.95| 14.05| 1024| 0| 32| 0| 1681| 0| 13| 863352| 863429| 887505| 0.00| 0.00
2 250| 256| 14344.74| 14.62| 987| 0| 32| 0| 1698| 0| 13| 860760| 860843| 882154| 0.00| 0.00
% | 0.0| -0.3| +4.1| -3.6| 0| 0.0| 0| +1.0| 0| 0.0| -0.3| -0.3| -0.6| 0| 0
1 500| 256| 14365.89| 14.19| 1013| 0| 33| 0| 1769| 0| 13| 862029| 862099| 885852| 0.00| 0.00
2 500| 256| 14329.59| 14.62| 990| 0| 34| 0| 1830| 0| 13| 859852| 861233| 880082| 0.00| 0.00
% | 0.0| -0.3| +3.0| -2.3| 0| +3.0| 0| +3.4| 0| 0.0| -0.3| -0.1| -0.7| 0| 0
1 50| 512| 14273.07| 14.12| 1010| 0| 33| 0| 1742| 0| 13| 856460| 856524| 880356| 0.00| 0.00
2 50| 512| 14222.08| 14.72| 966| 0| 32| 0| 1698| 0| 12| 853398| 853468| 875621| 0.00| 0.00
% | 0.0| -0.4| +4.2| -4.4| 0| -3.0| 0| -2.5| 0| -7.7| -0.4| -0.4| -0.5| 0| 0
1 100| 512| 14236.34| 14.51| 982| 0| 34| 0| 1804| 0| 13| 854258| 854335| 876662| 0.00| 0.00
2 100| 512| 14147.89| 14.85| 953| 0| 34| 0| 1813| 0| 13| 848947| 849031| 871773| 0.00| 0.00
% | 0.0| -0.6| +2.3| -3.0| 0| 0.0| 0| +0.5| 0| 0.0| -0.6| -0.6| -0.6| 0| 0
1 250| 512| 14260.79| 14.53| 983| 0| 33| 0| 1760| 0| 13| 855721| 855791| 879099| 0.00| 0.00
2 250| 512| 14190.68| 14.87| 954| 0| 32| 0| 1698| 0| 13| 851517| 851580| 874119| 0.00| 0.00
% | 0.0| -0.5| +2.3| -3.0| 0| -3.0| 0| -3.5| 0| 0.0| -0.5| -0.5| -0.6| 0| 0
1 500| 512| 14273.71| 14.18| 1008| 0| 33| 0| 1769| 0| 13| 856499| 856562| 879984| 0.00| 0.00
2 500| 512| 14213.87| 14.72| 967| 0| 34| 0| 1830| 0| 13| 852907| 852976| 875328| 0.00| 0.00
% | 0.0| -0.4| +3.8| -4.1| 0| +3.0| 0| +3.4| 0| 0.0| -0.4| -0.4| -0.5| 0| 0
1 50| 1024| 14049.77| 13.89| 1024| 0| 32| 0| 1708| 0| 12| 843061| 843134| 863697| 0.00| 0.00
2 50| 1024| 13980.25| 14.38| 980| 0| 32| 0| 1698| 0| 12| 838890| 838973| 858350| 0.00| 0.00
% | 0.0| -0.5| +3.5| -4.3| 0| 0.0| 0| -0.6| 0| 0.0| -0.5| -0.5| -0.6| 0| 0
1 100| 1024| 14025.66| 13.32| 1066| 0| 33| 0| 1769| 0| 13| 841616| 841685| 864460| 0.00| 0.00
2 100| 1024| 13993.30| 14.82| 946| 0| 34| 0| 1830| 0| 12| 839676| 839735| 859288| 0.00| 0.00
% | 0.0| -0.2| +11.3| -11.3| 0| +3.0| 0| +3.4| 0| -7.7| -0.2| -0.2| -0.6| 0| 0
1 250| 1024| 14060.15| 13.90| 1023| 0| 35| 0| 1848| 0| 12| 843688| 843752| 864475| 0.00| 0.00
2 250| 1024| 13982.47| 15.34| 913| 0| 34| 0| 1830| 0| 12| 839026| 839089| 859914| 0.00| 0.00
% | 0.0| -0.6| +10.4| -10.8| 0| -2.9| 0| -1.0| 0| 0.0| -0.6| -0.6| -0.5| 0| 0
1 500| 1024| 14051.14| 13.80| 1024| 0| 33| 0| 1716| 0| 13| 843144| 843212| 862981| 0.00| 0.00
2 500| 1024| 14013.95| 15.27| 918| 0| 32| 0| 1681| 0| 13| 840915| 840983| 862635| 0.00| 0.00
% | 0.0| -0.3| +10.7| -10.4| 0| -3.0| 0| -2.0| 0| 0.0| -0.3| -0.3| -0.0| 0| 0
[-- Attachment #3: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC 7/11] virtio_pci: new, capability-aware driver.
From: Rusty Russell @ 2011-12-19 6:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Christian Borntraeger, Sasha Levin, Pawel Moll, virtualization
In-Reply-To: <20111218101831.GB30374@redhat.com>
On Sun, 18 Dec 2011 12:18:32 +0200, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Fri, Dec 16, 2011 at 12:20:08PM +1030, Rusty Russell wrote:
> > Perhaps a new feature VIRTIO_F_UNSTABLE? Which (unlike other features)
> > appears and vanishes around config writes by either side? Kind of a
> > hack though...
>
> Not sure how this can work in such a setup: when would guest
> check this bit to avoid races?
> A separate registers also seems nicer than a flag.
>
> Some other possible design choices:
> - a flag to signal config accesses in progress by guest
> host would need to buffer changes and apply them in one go
> when flag is cleared
> - a register to make host get/set config in guest memory
> - use a control vq for all devices
- seqlock-style generation count register(s)? Has the advantage of
being a noop if things never change.
- continue to ignore it ;)
And yes, it's a more general problem than virtio_pci...
Cheers,
Rusty.
^ permalink raw reply
* Re: [RFC] virtio: use mandatory barriers for remote processor vdevs
From: Amos Kong @ 2011-12-19 7:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: kvm, Michael S. Tsirkin, linux-kernel, virtualization, rhod,
linux-arm-kernel
In-Reply-To: <1324262474.30454.12.camel@pasglop>
On 19/12/11 10:41, Benjamin Herrenschmidt wrote:
> On Mon, 2011-12-19 at 10:19 +0800, Amos Kong wrote:
>
>> I tested with the same environment and scenarios.
>> tested one scenarios for three times and compute the average for more
>> precision.
>>
>> Thanks, Amos
>>
>> --------- compare results -----------
>> Mon Dec 19 09:51:09 2011
>>
>> 1 - avg-old.netperf.exhost_guest.txt
>> 2 - avg-fixed.netperf.exhost_guest.txt
>
> The output is word wrapped and generally unreadable. Any chance you can
> provide us with a summary of the outcome ?
>
> Cheers,
> Ben.
Hi Ben,
The change of TCP_RR Throughput is very small.
external host -> guest: Some of throughput of TCP_STREAM and TCP_MAERTS
reduced a little.
local host -> guest: Some of throughput of TCP_STREAM and TCP_MAERTS
increased a little.
About compare result format:
---------------------------
>> 1 - avg-old.netperf.exhost_guest.txt
average result (tested 3 times) file of test 1
>> 2 - avg-fixed.netperf.exhost_guest.txt
average result file of test 2
>>
>> ======
>> TCP_STREAM
^^^ protocol
>> sessions| size|throughput| cpu| normalize| #tx-pkts| #rx-pkts| #tx-byts| #rx-byts| #re-trans| #tx-intr| #rx-intr| #io_exit| #irq_inj|#tpkt/#exit| #rpkt/#irq
>> 1 1| 64| 1073.54| 10.50| 102| ....
^^^ average result of old kernel, start netserver in guest, start
netperf client(s) in external host
>> 2 1| 64| 1079.44| 10.29| 104| ....
^^^ average result of fixed kernel
>> % | 0.0| +0.5| -2.0| +2.0| ....
^^^ augment rate between test1 and test2
--------
sessions: netperf clients number
size: request/response sizes
#rx-pkts: received packets number
#rx-byts: received bytes number
#rx-intr: interrupt number for receive
#io_exit: io exit number
#irq_inj: injected irq number
Thanks, Amos.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox