Re: [Qemu-devel] [PATCH 01/12] migration: do not wait if no free thread

[Xiao Guangrong <guangrong.xiao@gmail.com>]

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 <xiaoguangrong@tencent.com>
>>>>>
>>>>> 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! :)