[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: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH 0/2] optimize waiting for free thread to do compression |
Date: |
Fri, 21 Dec 2018 16:10:55 +0800 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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,
--
Peter Xu