qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Sanidhya Kashyap <sanidhya.iiith@gmail.com>,
	qemu list <qemu-devel@nongnu.org>
Cc: Amit Shah <amit.shah@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4 7/8] BitmapLog: get the information about the parameters
Date: Fri, 18 Jul 2014 06:35:04 -0600	[thread overview]
Message-ID: <53C91478.5020709@redhat.com> (raw)
In-Reply-To: <1405596081-29701-8-git-send-email-sanidhya.iiith@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3915 bytes --]

On 07/17/2014 05:21 AM, Sanidhya Kashyap wrote:
> Added the qmp interface to know about the information of the bitmap dump
> process. When the command is executed, one can know about the current epoch
> value in which the process is in, the total iterations value and the current
> frequency value.
> 
> Currently, I do not think that that one needs to modify the other values
> except frequency, so that is why I have not added the generic set-tuning
> interface. If required, I will add it.
> 
> Signed-off-by: Sanidhya Kashyap <sanidhya.iiith@gmail.com>
> ---
>  qapi-schema.json | 31 +++++++++++++++++++++++++++++++
>  qmp-commands.hx  | 24 ++++++++++++++++++++++++
>  savevm.c         | 26 ++++++++++++++++++++++++++
>  3 files changed, 81 insertions(+)

Ah, this answers one of my questions in 6/8.  I would reorder the series
and put this right after 3/8 (being able to query initial values is
still useful, whether or not we also add on-the-fly tuning commands).

> 
> diff --git a/qapi-schema.json b/qapi-schema.json
> index 90977eb..1b09235d 100644
> --- a/qapi-schema.json
> +++ b/qapi-schema.json
> @@ -3487,6 +3487,24 @@
>  { 'command': 'rtc-reset-reinjection' }
>  
>  ##
> +# @BitmapLogStateInfo
> +#
> +# Provides information for the bitmap logging process
> +#
> +# @currepoch: provides the value of the running epoch value

No need to abbreviate.  And given my naming question in 3/8, would this
be better as: current-iteration

> +#
> +# @epochs: provides the information about the actual epoch

and iterations

Wait.  Is this number a constant (the number requested when logging
started, no matter what currepoch is)...[1]


> +#
> +# @frequency: the time difference in milliseconds between each epcoh

s/epcoh/epoch/ (or iteration)

> +#
> +# Since 2.2
> +##
> +{ 'type': 'BitmapLogStateInfo',
> +  'data': { 'currepoch': 'int',
> +            'epochs':    'int',
> +            'frequency': 'int' } }
> +
> +##
>  # @log-dirty-bitmap
>  #
>  # dumps the dirty bitmap to a file by logging the
> @@ -3524,3 +3542,16 @@
>  { 'command': 'log-dirty-bitmap-set-frequency',
>    'data': {'frequency': 'int' } }
>  
> +##
> +# @log-dirty-bitmap-get-tuning

Most query interfaces are in the query- namespace.  Maybe this would be
better as query-log-dirty-bitmap?

> +#
> +# Get the current values of the parameters involved in  bitmap logging process

Accidental double space.

> +#
> +# This command returns the following elements in the form of BitmapLogStateInfo:
> +# - currepoch: current epoch value
> +# - epochs: total epochs for which the bitmap dumping will continue

...[1]or is it the number of iterations remaining (that is,
currepoch+epochs is the original value, and both numbers are changing as
iterations progress)?  Rather than duplicate the parameters in two
places (and with different information, which led to my question about
semantics), it might be nicer to just mention here that the information
is returned as a BitmapLogStateInfo and be done with it (the user can go
look up the documentation of that struct).

> +# - frequently: the current sleep interval between each epoch

s/frequently/frequency/

> +#
> +# Since 2.2
> +##
> +{ 'command': 'log-dirty-bitmap-get-tuning', 'returns': 'BitmapLogStateInfo' }

> +Get the parameters information
> +
> +- "currepoch": the current epoch going on
> +- "epochs" the total number of assigned epochs
> +- "frequency": the sleep interval between each epoch (in milliseconds)
> +
> +Example:
> +
> +-> { "execute": "log-dirty-bitmap-get-tuning" }
> +<- { "return": {
> +            "currepoch": 3
> +            "epochs": 100
> +            "frequency": 100 } }

Invalid JSON.  You are missing two commas.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2014-07-18 12:35 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-17 11:21 [Qemu-devel] [PATCH v4 0/8] Obtain dirty bitmap via VM logging Sanidhya Kashyap
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 1/8] enable sharing of the function between migration and bitmap dump Sanidhya Kashyap
2014-07-18 11:00   ` Dr. David Alan Gilbert
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 2/8] RunState: added two new flags for bitmap dump and migration process Sanidhya Kashyap
2014-07-18 11:02   ` Dr. David Alan Gilbert
2014-07-18 12:16   ` Eric Blake
2014-07-18 18:01     ` Sanidhya Kashyap
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 3/8] BitmapLog: bitmap dump code via QAPI framework with runstates Sanidhya Kashyap
2014-07-18 11:12   ` Dr. David Alan Gilbert
2014-07-18 18:18     ` Sanidhya Kashyap
2014-07-18 11:14   ` Dr. David Alan Gilbert
2014-07-18 18:09     ` Sanidhya Kashyap
2014-07-18 12:20   ` Eric Blake
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 4/8] BitmapLog: hmp interface for dirty bitmap dump Sanidhya Kashyap
2014-07-18 11:15   ` Dr. David Alan Gilbert
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 5/8] BitmapLog: cancel mechanism for an already running dump bitmap process Sanidhya Kashyap
2014-07-18 12:22   ` Eric Blake
2014-07-18 17:51     ` Sanidhya Kashyap
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 6/8] BitmapLog: set the frequency of the " Sanidhya Kashyap
2014-07-18 12:28   ` Eric Blake
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 7/8] BitmapLog: get the information about the parameters Sanidhya Kashyap
2014-07-18 12:35   ` Eric Blake [this message]
2014-07-18 17:41     ` Sanidhya Kashyap
2014-07-17 11:21 ` [Qemu-devel] [PATCH v4 8/8] BitmapLog: python script for extracting bitmap from a binary file Sanidhya Kashyap
2014-07-18 11:17   ` Dr. David Alan Gilbert
2014-07-18 10:56 ` [Qemu-devel] [PATCH v4 0/8] Obtain dirty bitmap via VM logging Dr. David Alan Gilbert
2014-07-18 13:42   ` Eric Blake
2014-07-18 17:28   ` Sanidhya Kashyap
2014-07-18 17:42     ` Dr. David Alan Gilbert
2014-07-18 12:39 ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53C91478.5020709@redhat.com \
    --to=eblake@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=sanidhya.iiith@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).