[Top][All Lists]

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

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

From: Xiao Guangrong
Subject: Re: [Qemu-devel] [PATCH 01/12] migration: do not wait if no free thread
Date: Tue, 12 Jun 2018 10:42:25 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

On 06/11/2018 03:39 PM, Peter Xu wrote:
On Mon, Jun 04, 2018 at 05:55:09PM +0800, address@hidden wrote:
From: Xiao Guangrong <address@hidden>

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

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 <address@hidden>
  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();

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.

reply via email to

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