From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFjpg-0002hM-1o for qemu-devel@nongnu.org; Tue, 30 May 2017 12:17:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFjpc-0002Vp-TA for qemu-devel@nongnu.org; Tue, 30 May 2017 12:17:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33426) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dFjpc-0002VZ-MU for qemu-devel@nongnu.org; Tue, 30 May 2017 12:17:16 -0400 From: Juan Quintela In-Reply-To: <1495642203-12702-5-git-send-email-felipe@nutanix.com> (Felipe Franciosi's message of "Wed, 24 May 2017 17:10:03 +0100") References: <1495642203-12702-1-git-send-email-felipe@nutanix.com> <1495642203-12702-5-git-send-email-felipe@nutanix.com> Reply-To: quintela@redhat.com Date: Tue, 30 May 2017 18:17:09 +0200 Message-ID: <874lw2e2uy.fsf@secure.mitica> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 4/4] migration: use dirty_rate_high_cnt more aggressively List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Felipe Franciosi Cc: Peter Xu , "Jason J. Herne" , amit Shah , "Dr. David Alan Gilbert" , Malcolm Crossley , "qemu-devel@nongnu.org" Felipe Franciosi wrote: > The commit message from 070afca25 suggests that dirty_rate_high_cnt > should be used more aggressively to start throttling after two > iterations instead of four. The code, however, only changes the auto > convergence behaviour to throttle after three iterations. This makes the > behaviour more aggressive by kicking off throttling after two iterations > as originally intended. > > Signed-off-by: Felipe Franciosi Reviewed-by: Juan Quintela First, Felipe is doing performance testing with the changes. Second, if you want autoconverge slower, you can use smaller increments. So, I think that this is ok. It is more, if you want you can send numbers of your workloads with current parameter and removing it altogether to convince me that it is a good idea just to drop it. Thanks, Juan.