On Tue, Oct 16, 2012 at 2:23 PM, Edivaldo de Araujo Pereira
<edivaldoapere...@yahoo.com.br> wrote:
> Hi Stefan
>
> I finally could revert that commit in the latest snapshot; problem was I
> needed to revert one later, that modified hw/virtio-serial-bus.c
> accordingly; after that reversion, the regression in network performance
> went completely away; this confirms my previous identification of the
> commit that caused it.
>
> Additionally, I tested your last suggestion, to change '<' to '<=', and
> that didn't help; the problem was still there.
>
> By the way, the performance gain I observed ,of about 25~30 % when using
> a tun/tap, was in fact just apparent, because it was result of a greater
> use of cpu, so it was achieved only when the host was idle; when I
> stress the host, with a lot of concurrent guests generating traffic,
> there is no gain at all.
>
> Just for confirmation, this is the performance I get with latest
> snapshot (8b4a3df8081f3e6f1061ed5cbb303ad623ade66b) running wget in the
> guest:
>
> $ wget -O /dev/null http://172.18.1.1/bpd.iso
> --2012-10-16 09:10:18-- http://172.18.1.1/bpd.iso
> Connecting to 172.18.1.1:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 358979584 (342M) [application/x-iso9660-image]
> Saving to: `/dev/null'
> 100%[======================================================>] 358.979.584
> 29,7M/s in 11s
> 2012-10-16 09:10:29 (30,3 MB/s) - `/dev/null' saved [358979584/358979584]
>
> The same wget, using the same snapshot, but with that commit reverted
> is:
>
> $ wget -O /dev/null http://172.18.1.1/bpd.iso
> --2012-10-16 09:15:12-- http://172.18.1.1/bpd.iso
> Connecting to 172.18.1.1:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 358979584 (342M) [application/x-iso9660-image]
> Saving to: `/dev/null'
> 100%[======================================================>] 358.979.584
> 180M/s in 1,9s
> 2012-10-16 09:15:14 (180 MB/s) - `/dev/null' saved [358979584/358979584]
>
> So, as I can see, there is no doubt: that commit is the culprit; as it
> was intended to be related just to the quality of the source code (at
> least as I can see), but implied in such a cost in performance, I think
> it would be better to revert it.
Hi Amit,
Edivaldo has identified the following commit responsible for a network
performance regression he sees:
commit 0d8d7690850eb0cf2b2b60933cf47669a6b6f18f
Author: Amit Shah <amit.s...@redhat.com>
Date: Tue Sep 25 00:05:15 2012 +0530
virtio: Introduce virtqueue_get_avail_bytes()
I guess this is because we now iterate the entire descriptor chain to
check available space instead of returning early.
Do you want to propose a patch to fix it?
Stefan
