From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Xu Subject: Re: [PATCH 06/12] migration: do not detect zero page for compression Date: Tue, 19 Jun 2018 15:30:34 +0800 Message-ID: <20180619073034.GA14814@xz-mi> References: <20180604095520.8563-1-xiaoguangrong@tencent.com> <20180604095520.8563-7-xiaoguangrong@tencent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com, Xiao Guangrong , dgilbert@redhat.com, qemu-devel@nongnu.org, wei.w.wang@intel.com, jiang.biao2@zte.com.cn, pbonzini@redhat.com To: guangrong.xiao@gmail.com Return-path: Content-Disposition: inline In-Reply-To: <20180604095520.8563-7-xiaoguangrong@tencent.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel2=m.gmane.org@nongnu.org Sender: "Qemu-devel" List-Id: kvm.vger.kernel.org On Mon, Jun 04, 2018 at 05:55:14PM +0800, guangrong.xiao@gmail.com wrote: > From: Xiao Guangrong > > Detecting zero page is not a light work, we can disable it > for compression that can handle all zero data very well Is there any number shows how the compression algo performs better than the zero-detect algo? Asked since AFAIU buffer_is_zero() might be fast, depending on how init_accel() is done in util/bufferiszero.c. >>From compression rate POV of course zero page algo wins since it contains no data (but only a flag). Regards, -- Peter Xu