From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fDtib-00080o-Nn for qemu-devel@nongnu.org; Wed, 02 May 2018 11:31:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fDtiX-0000J6-4B for qemu-devel@nongnu.org; Wed, 02 May 2018 11:30:57 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:55042 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fDtiW-0000Hm-Tn for qemu-devel@nongnu.org; Wed, 02 May 2018 11:30:53 -0400 Date: Wed, 2 May 2018 16:30:39 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20180502153039.GF2679@work-vm> References: <20180428081045.8878-1-xiaoguangrong@tencent.com> <20180502024653.GB25938@xz-mi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180502024653.GB25938@xz-mi> Subject: Re: [Qemu-devel] [PATCH] migration: fix saving normal page even if it's been compressed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu , quintela@redhat.com Cc: guangrong.xiao@gmail.com, pbonzini@redhat.com, mst@redhat.com, mtosatti@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org, jiang.biao2@zte.com.cn, wei.w.wang@intel.com, Xiao Guangrong * Peter Xu (peterx@redhat.com) wrote: > On Sat, Apr 28, 2018 at 04:10:45PM +0800, guangrong.xiao@gmail.com wrote: > > From: Xiao Guangrong > > > > Fix the bug introduced by da3f56cb2e767016 (migration: remove > > ram_save_compressed_page()), It should be 'return' rather than > > 'res' > > > > Sorry for this stupid mistake :( > > > > Signed-off-by: Xiao Guangrong > > Reviewed-by: Peter Xu > > So is that only a performance degradation without this fix (since > AFAIU the compressing pages will be sent twice)? Thanks, It might be a bit more messy than that; because I think the 'compress_page_with_multi_thread' hands it to a compression thread to compress and write, but I don't think it waits for it. So I think you'll end up with this being written at the same time as the uncompressed data is written - I'm not sure what the other end receives. (Which makes me realise I don't think I understand how the compression threads are safe with their writing data out). Anyway, I think we should get this one in quickly. Dave > > --- > > migration/ram.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/migration/ram.c b/migration/ram.c > > index 01cc815410..699546cc43 100644 > > --- a/migration/ram.c > > +++ b/migration/ram.c > > @@ -1490,7 +1490,7 @@ static int ram_save_target_page(RAMState *rs, PageSearchStatus *pss, > > * CPU resource. > > */ > > if (block == rs->last_sent_block && save_page_use_compression(rs)) { > > - res = compress_page_with_multi_thread(rs, block, offset); > > + return compress_page_with_multi_thread(rs, block, offset); > > } > > > > return ram_save_page(rs, pss, last_stage); > > -- > > 2.14.3 > > > > -- > Peter Xu -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK