From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj5Af-0003B0-Bb for qemu-devel@nongnu.org; Wed, 20 Nov 2013 05:38:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vj5AW-0006C2-6o for qemu-devel@nongnu.org; Wed, 20 Nov 2013 05:38:09 -0500 Received: from mail-ee0-x22c.google.com ([2a00:1450:4013:c00::22c]:48540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vj5AV-0006Bq-VQ for qemu-devel@nongnu.org; Wed, 20 Nov 2013 05:38:00 -0500 Received: by mail-ee0-f44.google.com with SMTP id d51so3909529eek.3 for ; Wed, 20 Nov 2013 02:37:59 -0800 (PST) Sender: Paolo Bonzini Message-ID: <528C9103.9050608@redhat.com> Date: Wed, 20 Nov 2013 11:37:55 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <528B1F0B.40001@redhat.com> <528BA5F7.4040105@weilnetz.de> <528BA8ED.7000507@redhat.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH for-1.7?] the calculation of bytes_xfer in qemu_put_buffer() is wrong List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Wangting (Kathy)" Cc: "zhangmin (S)" , Juan Quintela , Luonengjun , "qemu-devel@nongnu.org" , Stefan Weil , "Chentao (Boby)" , "Wangrui (K)" , Anthony Liguori , Qinling , "Wubin (H)" Il 20/11/2013 06:28, Wangting (Kathy) ha scritto: > Hi Paolo and Stefan, > > I am really sorry for my email before that I didn't say clearly about > the bug fix. > > f->bytes_xfer means the number of bytes which is send from source to > destination during the migration. It is limited by the f->xfer_limit > which is converted from bandwidth. That means if bytes_xfer is larger > than the limit, the current iteration will not do block and memory > migration util the next iteration. > > But in function qemu_put_buffer, the statistics is wrong. The size of > block migration is 1MB for each block, but the buffer size for > sending is IO_BUF_SIZE(32768bytes). When it need to be send, 1MB > block will be divided into small trunks, so f->bytes_xfer should be > increased by the size of the small trunks every time which is > actually send, in function qemu_put_buffer it should be the variable > "l". > > Otherwise, f->bytes_xfer will be increased by (small trunks number * > 1MB) while sending 1MB block, it is much larger than the size which > is actually send, and it will soon be reached to the size of > f->xfer_limit, so the current iteration will send less data blocks > than expected. > > If you have any questions, please let me know, thank you very much. Thank you very much. Juan, I guess you need to prepare another pull request. Paolo