On 06/11/2018 03:39 PM, Peter Xu wrote:
On Mon, Jun 04, 2018 at 05:55:09PM +0800, guangrong.x...@gmail.com wrote:
From: Xiao Guangrong <xiaoguangr...@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.
Furthermore, we really need to improve this optimization if it hurts
any case rather than leaving a option to the user. :)
Signed-off-by: Xiao Guangrong <xiaoguangr...@tencent.com>
---
migration/ram.c | 34 +++++++++++++++-------------------
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/migration/ram.c b/migration/ram.c
index 5bcbf7a9f9..0caf32ab0a 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1423,25 +1423,18 @@ static int compress_page_with_multi_thread(RAMState
*rs, RAMBlock *block,
thread_count = migrate_compress_threads();
qemu_mutex_lock(&comp_done_lock);
Can we drop this lock in this case?
The lock is used to protect comp_param[].done...
Well, we are able to possibly remove it if we redesign the implementation, e.g,
use atomic
access for comp_param.done, however, it still can not work efficiently i
believe. Please see
more in the later reply to your comments in the cover-letter.
