qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] optimize waiting for free thread to do comp


From: xiaoguangrong(Xiao Guangrong)
Subject: Re: [Qemu-devel] [PATCH 0/2] optimize waiting for free thread to do compression(Internet mail)
Date: Mon, 24 Dec 2018 13:36:14 +0000

On 12/21/18 4:11 PM, Peter Xu wrote:
> On Thu, Dec 13, 2018 at 03:57:25PM +0800, address@hidden wrote:
>> From: Xiao Guangrong <address@hidden>
>>
>> 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, compress-wait-thread-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 if 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
> 
> Sounds reasonable to me, though it looks like there're only three
> options: on, off, adaptive.  Should we squash the two parameters?

Thanks for your review, Peter!

That's good to me, if other guys do not have objects, i will do it in the
next version.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]