From: "Zhang, Chen" <chen.zhang@intel.com>
To: Lukas Straub <lukasstraub2@web.de>, Derek Su <dereksu@qnap.com>
Cc: "lizhijian@cn.fujitsu.com" <lizhijian@cn.fujitsu.com>,
"chyang@qnap.com" <chyang@qnap.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"ctcheng@qnap.com" <ctcheng@qnap.com>,
"jwsu1986@gmail.com" <jwsu1986@gmail.com>
Subject: RE: [PATCH v4 2/2] net/colo-compare.c: handling of the full primary or secondary queue
Date: Thu, 9 Apr 2020 06:59:36 +0000 [thread overview]
Message-ID: <3f0534dbaa744ee4bff9f11615a3b964@intel.com> (raw)
In-Reply-To: <20200408211842.2c0f1e4a@luklap>
> -----Original Message-----
> From: Lukas Straub <lukasstraub2@web.de>
> Sent: Thursday, April 9, 2020 3:19 AM
> To: Derek Su <dereksu@qnap.com>
> Cc: qemu-devel@nongnu.org; lizhijian@cn.fujitsu.com; chyang@qnap.com;
> jasowang@redhat.com; ctcheng@qnap.com; Zhang, Chen
> <chen.zhang@intel.com>; jwsu1986@gmail.com
> Subject: Re: [PATCH v4 2/2] net/colo-compare.c: handling of the full primary
> or secondary queue
>
> On Sat, 28 Mar 2020 20:46:46 +0800
> Derek Su <dereksu@qnap.com> wrote:
>
> > The pervious handling of the full primary or queue is only dropping
> > the packet. If there are lots of clients to the guest VM, the "drop"
> > will lead to the lost of the networking connection until next
> > checkpoint.
> >
> > To address the issue, this patch drops the packet firstly.
> > Then, do checkpoint and flush packets.
> >
> > Signed-off-by: Derek Su <dereksu@qnap.com>
>
> Hello,
> I had a look at this again and did some benchmarking.
> First just qemu 5.0-rc1 with my bugfixes
> ( https://lists.nongnu.org/archive/html/qemu-devel/2020-
> 04/msg01432.html ) Then qemu 5.0-rc1 with my bugfixes and this patch
> series.
>
> This commit hurts performance too much:
> Client-to-server bandwidth falls from ~45.9 Mbit/s to 22.9 Mbit/s.
> Server-to-client bandwidth falls from ~6.3 Mbit/s to just ~674 Kbit/s.
> Average latency rises from ~197ms to ~397ms.
>
> Meanwhile the packet loss without this commit is negligible, only 1-2 ping
> packets got lost during each test run.
>
> Instead I think we should just turn the error message into a trace so it
> doesn't flood the logs.
We re-test this patch, Lukas is right.
Sorry for the original idea, looks like it did not show better performance in the test.
Agree with Lukas's comments. Derek, can you please change it?
Thanks
Zhang Chen
>
> Regards,
> Lukas Straub
next prev parent reply other threads:[~2020-04-09 7:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-28 12:46 [PATCH v4 0/2] COLO: handling of the full primary or secondary queue Derek Su
2020-03-28 12:46 ` [PATCH v4 1/2] net/colo-compare.c: Fix memory leak in packet_enqueue() Derek Su
2020-03-31 1:14 ` Zhang, Chen
2020-04-05 22:12 ` Lukas Straub
2020-03-28 12:46 ` [PATCH v4 2/2] net/colo-compare.c: handling of the full primary or secondary queue Derek Su
2020-03-31 1:15 ` Zhang, Chen
2020-04-05 22:11 ` Lukas Straub
2020-04-08 19:18 ` Lukas Straub
2020-04-09 6:59 ` Zhang, Chen [this message]
2020-04-09 7:10 ` Derek Su
2020-04-09 9:02 ` Zhang, Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3f0534dbaa744ee4bff9f11615a3b964@intel.com \
--to=chen.zhang@intel.com \
--cc=chyang@qnap.com \
--cc=ctcheng@qnap.com \
--cc=dereksu@qnap.com \
--cc=jasowang@redhat.com \
--cc=jwsu1986@gmail.com \
--cc=lizhijian@cn.fujitsu.com \
--cc=lukasstraub2@web.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).