From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiao Guangrong Subject: Re: [PATCH 01/12] migration: do not wait if no free thread Date: Thu, 14 Jun 2018 11:19:42 +0800 Message-ID: <089249ff-7f39-44db-310d-ae9ba7912b33@gmail.com> References: <20180604095520.8563-1-xiaoguangrong@tencent.com> <20180604095520.8563-2-xiaoguangrong@tencent.com> <20180611073920.GJ7736@xz-mi> <20180612031503.GL7736@xz-mi> <20180613154314.GI2676@work-vm> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, mst@redhat.com, mtosatti@redhat.com, Xiao Guangrong , qemu-devel@nongnu.org, wei.w.wang@intel.com, pbonzini@redhat.com, jiang.biao2@zte.com.cn To: "Dr. David Alan Gilbert" , Peter Xu Return-path: In-Reply-To: <20180613154314.GI2676@work-vm> Content-Language: en-US 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 06/13/2018 11:43 PM, Dr. David Alan Gilbert wrote: > * Peter Xu (peterx@redhat.com) wrote: >> On Tue, Jun 12, 2018 at 10:42:25AM +0800, Xiao Guangrong wrote: >>> >>> >>> On 06/11/2018 03:39 PM, Peter Xu wrote: >>>> On Mon, Jun 04, 2018 at 05:55:09PM +0800, guangrong.xiao@gmail.com wrote: >>>>> From: Xiao Guangrong >>>>> >>>>> Instead of putting the main thread to sleep state to wait for >>>>> free compression thread, we can directly post it out as normal >>>>> page that reduces the latency and uses CPUs more efficiently >>>> >>>> The feature looks good, though I'm not sure whether we should make a >>>> capability flag for this feature since otherwise it'll be hard to >>>> switch back to the old full-compression way no matter for what >>>> reason. Would that be a problem? >>>> >>> >>> We assume this optimization should always be optimistic for all cases, >>> particularly, we introduced the statistics of compression, then the user >>> should adjust its parameters based on those statistics if anything works >>> worse. >> >> Ah, that'll be good. >> >>> >>> Furthermore, we really need to improve this optimization if it hurts >>> any case rather than leaving a option to the user. :) >> >> Yeah, even if we make it a parameter/capability we can still turn that >> on by default in new versions but keep the old behavior in old >> versions. :) The major difference is that, then we can still _have_ a >> way to compress every page. I'm just thinking if we don't have a >> switch for that then if someone wants to measure e.g. how a new >> compression algo could help VM migration, then he/she won't be >> possible to do that again since the numbers will be meaningless if >> that bit is out of control on which page will be compressed. >> >> Though I don't know how much use it'll bring... But if that won't be >> too hard, it still seems good. Not a strong opinion. > > I think that is needed; it might be that some users have really awful > networking and need the compression; I'd expect that for people who turn > on compression they really expect the slowdown because they need it for > their network, so changing that is a bit odd. People should make sure the system has enough CPU resource to do compression as well, so the perfect usage is that the 'busy-rate' is low enough i think. However, it's not a big deal, i will introduce a parameter, maybe, compress-wait-free-thread. Thank you all, Dave and Peter! :)