From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53450) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4IhO-0003uO-2I for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:28:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a4IhJ-0004nt-52 for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:28:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a4IhI-0004n2-VU for qemu-devel@nongnu.org; Wed, 02 Dec 2015 20:28:37 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 88477C0CC637 for ; Thu, 3 Dec 2015 01:28:36 +0000 (UTC) Date: Thu, 3 Dec 2015 09:28:25 +0800 From: Peter Xu Message-ID: <20151203012823.GA19312@pxdev.xzpeter.org> References: <1448976530-15984-1-git-send-email-peterx@redhat.com> <1448976530-15984-9-git-send-email-peterx@redhat.com> <20151202011131.GE9399@ad.usersys.redhat.com> <565F0420.10409@redhat.com> <20151202152134.GA18589@pxdev.xzpeter.org> <565F15CC.4020706@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <565F15CC.4020706@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 08/11] dump-guest-memory: add qmp event DUMP_COMPLETED List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: drjones@redhat.com, Fam Zheng , armbru@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com, lcapitulino@redhat.com, lersek@redhat.com On Wed, Dec 02, 2015 at 09:01:16AM -0700, Eric Blake wrote: > On 12/02/2015 08:21 AM, Peter Xu wrote: > > Will the raw memory total size useful in any way? I am totally ok to > > add this, just failed to find a way for user to use it besides > > calculating finished work during dump... :( > > Good idea. You never know if it will be helpful, but the information is > basically free to provide and doesn't seem like too much of a > maintenance burden to promise to always include the total. And in the > case of an error, knowing the final values of complete/total might also > be useful to see how far things got before failure (for example, if it > failed because of ENOSPACE, knowing how much was complete may give an > idea of how much additional space should be added before retrying). Yes, it's more meaningful when it fails. And maybe you are right, it's free to provide it. :) I can add it in v5. One thing to mention is that, since the written_byte field is only for raw memory size, which means (e.g., for kdump-zlib), the number could first goes to 70% of total very quickly in less than a second (possibly due to zero pages, so actually very little data is written to disk), then it will use another ten seconds to finish the rest 30% (which contains most of the data of the final dump file). So the number would still help little even with ENOSPACE. When user sees a 70% of "written" when failed, it will not mean "we need extra of 30% more spaces", it actually means "we need 100% more", but the user would never figure out the real situation from the number only. :( Thanks! Peter > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >