From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akuhk-0007Ta-Ul for qemu-devel@nongnu.org; Tue, 29 Mar 2016 10:33:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akuhg-0003wf-Ts for qemu-devel@nongnu.org; Tue, 29 Mar 2016 10:33:12 -0400 Received: from mail-am1on0144.outbound.protection.outlook.com ([157.56.112.144]:19537 helo=emea01-am1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akuhg-0003w1-D1 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 10:33:08 -0400 References: <1459260049-18231-1-git-send-email-den@openvz.org> <20160329170427-mutt-send-email-mst@redhat.com> From: "Denis V. Lunev" Message-ID: <56FA8EBF.3070100@openvz.org> Date: Tue, 29 Mar 2016 17:18:39 +0300 MIME-Version: 1.0 In-Reply-To: <20160329170427-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/1] virtio-balloon: reset the statistic timer to load device List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Pavel Butsykin , qemu-devel@nongnu.org, rkagan@virtuozzo.com On 03/29/2016 05:07 PM, Michael S. Tsirkin wrote: > On Tue, Mar 29, 2016 at 05:00:49PM +0300, Denis V. Lunev wrote: >> From: Pavel Butsykin >> >> If before loading snapshot we had set the timer of statistics, then after >> applying snapshot the expiry time would be irrelevant for the restored >> state of the virtual clocks. A simple fix is just to restart the timer >> after loading snapshot. >> >> For the user it may look like a long delay of statistics update after switch >> to the snapshot. >> >> Signed-off-by: Pavel Butsykin >> Reviewed-by: Roman Kagan >> Signed-off-by: Denis V. Lunev >> CC: Michael S. Tsirkin > I'm inclined to think we really should migrate the timer, > otherwise user might wait twice as long as expected ... this is not a big deal. This timer is a part of the QEMU state, which was configured for this exact running instance, not for the guest. Moreover, we have switched to new guest state which can be on the different CPU with different timings etc and thus we should let the guest to run for some time. In the perfect world you should not save the time to the migration state but save the time at reset callback and restore it here at postload, but this seems over engineering. Statistics delivery is "best effort", nobody will die if one shot will be missed.