From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [PATCH v2 0/3] optimize waiting for free thread to do compression Date: Fri, 11 Jan 2019 10:53:40 +0100 Message-ID: <87tvif5xln.fsf@dusky.pond.sub.org> References: <20190111063732.10484-1-xiaoguangrong@tencent.com> Mime-Version: 1.0 Content-Type: text/plain Cc: kvm@vger.kernel.org, quintela@redhat.com, mtosatti@redhat.com, Xiao Guangrong , qemu-devel@nongnu.org, peterx@redhat.com, dgilbert@redhat.com, wei.w.wang@intel.com, cota@braap.org, mst@redhat.com, pbonzini@redhat.com To: guangrong.xiao@gmail.com Return-path: In-Reply-To: <20190111063732.10484-1-xiaoguangrong@tencent.com> (guangrong xiao's message of "Fri, 11 Jan 2019 14:37:29 +0800") 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 guangrong.xiao@gmail.com writes: > From: Xiao Guangrong > > Changelog in v2: > squash 'compress-wait-thread-adaptive' into 'compress-wait-thread' based > on peter's suggestion > > > Currently we have two behaviors if all threads are busy to do compression, > the main thread mush wait one of them becoming free if @compress-wait-thread > set to on or the main thread can directly return without wait and post > the page out as normal one > > Both of them have its profits and short-comes, however, if the bandwidth is > not limited extremely so that compression can not use out all of it bandwidth, > at the same time, the migration process is easily throttled if we posted too > may pages as normal pages. None of them can work properly under this case > > In order to use the bandwidth more effectively, we introduce the third > behavior, adaptive, which make the main thread wait > if there is no bandwidth left or let the page go out as normal page if there > has enough bandwidth to make sure the migration process will not be > throttled > > Another patch introduces a new statistic, pages-per-second, as bandwidth > or mbps is not enough to measure the performance of posting pages out as > we have compression, xbzrle, which can significantly reduce the amount of > the data size, instead, pages-per-second is the one we want > > Performance data > ================ > We have limited the bandwidth to 300 > > Used Bandwidth Pages-per-Second > compress-wait-thread = on 951.66 mbps 131784 > > compress-wait-thread = off 2491.74 mbps 93495 > compress-wait-thread-adaptive 1982.94 mbps 162529 > = on I think you mean compress-wait-thread = adaptive here. Can you sketch use cases for all three settings? The resulting guidance should then be worked into documentation.