[Qemu-devel] [PATCH] augment info migrate with page status

[Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

This patch augments info migrate output with status about:
* ram bytes remaining
* ram bytes transferred
* ram bytes total

This should be enough for management tools to realize
whether or not there is progress in migration. We can
add more information later on, if the need arrives

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 migration.c |    3 +++
 sysemu.h    |    4 ++++
 vl.c        |   21 ++++++++++++++++++++-
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/migration.c b/migration.c
index b9e3368..a771f37 100644
--- a/migration.c
+++ b/migration.c
@@ -116,6 +116,9 @@ void do_info_migrate(Monitor *mon)
         switch (s->get_status(s)) {
         case MIG_STATE_ACTIVE:
             monitor_printf(mon, "active\n");
+            monitor_printf(mon, "transferred ram: %lu kbytes\n", ram_bytes_transferred() >> 10);
+            monitor_printf(mon, "remaining ram: %lu kbytes\n", ram_bytes_remaining() >> 10);
+            monitor_printf(mon, "total ram: %lu kbytes\n", ram_bytes_total() >> 10);
             break;
         case MIG_STATE_COMPLETED:
             monitor_printf(mon, "completed\n");
diff --git a/sysemu.h b/sysemu.h
index 7d65804..73f63df 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -28,6 +28,10 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
 void vm_start(void);
 void vm_stop(int reason);
 
+unsigned long ram_bytes_remaining(void);
+unsigned long ram_bytes_transferred(void);
+unsigned long ram_bytes_total(void);
+
 int64_t cpu_get_ticks(void);
 void cpu_enable_ticks(void);
 void cpu_disable_ticks(void);
diff --git a/vl.c b/vl.c
index d84ecef..74ad688 100644
--- a/vl.c
+++ b/vl.c
@@ -3236,6 +3236,7 @@ static int ram_save_block(QEMUFile *f)
 }
 
 static ram_addr_t ram_save_threshold = 10;
+static ram_addr_t bytes_transferred = 0;
 
 static ram_addr_t ram_save_remaining(void)
 {
@@ -3250,6 +3251,21 @@ static ram_addr_t ram_save_remaining(void)
     return count;
 }
 
+unsigned long ram_bytes_remaining(void)
+{
+    return ram_save_remaining() * TARGET_PAGE_SIZE;
+}
+
+unsigned long ram_bytes_transferred(void)
+{
+    return bytes_transferred;
+}
+
+unsigned long ram_bytes_total(void)
+{
+    return last_ram_offset;
+}
+
 static int ram_save_live(QEMUFile *f, int stage, void *opaque)
 {
     ram_addr_t addr;
@@ -3271,6 +3287,7 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
         int ret;
 
         ret = ram_save_block(f);
+        bytes_transferred += ret * TARGET_PAGE_SIZE;
         if (ret == 0) /* no more blocks */
             break;
     }
@@ -3280,7 +3297,9 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
     if (stage == 3) {
 
         /* flush all remaining blocks regardless of rate limiting */
-        while (ram_save_block(f) != 0);
+        while (ram_save_block(f) != 0) {
+            bytes_transferred += TARGET_PAGE_SIZE;
+        }
         cpu_physical_memory_set_dirty_tracking(0);
     }
 
-- 
1.5.6.6

[Qemu-devel] Re: [PATCH] augment info migrate with page status

[Anthony Liguori]

Glauber Costa wrote:
> This patch augments info migrate output with status about:
> * ram bytes remaining
> * ram bytes transferred
> * ram bytes total
>
> This should be enough for management tools to realize
> whether or not there is progress in migration. We can
> add more information later on, if the need arrives
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
>  migration.c |    3 +++
>  sysemu.h    |    4 ++++
>  vl.c        |   21 ++++++++++++++++++++-
>  3 files changed, 27 insertions(+), 1 deletions(-)
>
> diff --git a/migration.c b/migration.c
> index b9e3368..a771f37 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -116,6 +116,9 @@ void do_info_migrate(Monitor *mon)
>          switch (s->get_status(s)) {
>          case MIG_STATE_ACTIVE:
>              monitor_printf(mon, "active\n");
> +            monitor_printf(mon, "transferred ram: %lu kbytes\n", ram_bytes_transferred() >> 10);
> +            monitor_printf(mon, "remaining ram: %lu kbytes\n", ram_bytes_remaining() >> 10);
> +            monitor_printf(mon, "total ram: %lu kbytes\n", ram_bytes_total() >> 10);
>   

ram_addr_t isn't %lu.  It's 64-bit.  There's a PRI macro somewhere for it...

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] Re: [PATCH] augment info migrate with page status

[Avi Kivity]

Anthony Liguori wrote:
>> +            monitor_printf(mon, "transferred ram: %lu kbytes\n", 
>> ram_bytes_transferred() >> 10);
>> +            monitor_printf(mon, "remaining ram: %lu kbytes\n", 
>> ram_bytes_remaining() >> 10);
>> +            monitor_printf(mon, "total ram: %lu kbytes\n", 
>> ram_bytes_total() >> 10);
>>   
>
> ram_addr_t isn't %lu.  It's 64-bit.  There's a PRI macro somewhere for 
> it...

It actually is a %lu.  Unless kqemu is enabled.  Looks like we need a 
PRI_ram_addr, or to drop C as the implementation language.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

This patch augments info migrate output with status about:
* ram bytes remaining
* ram bytes transferred
* ram bytes total

This should be enough for management tools to realize
whether or not there is progress in migration. We can
add more information later on, if the need arrives

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 migration.c |    3 +++
 sysemu.h    |    4 ++++
 vl.c        |   21 ++++++++++++++++++++-
 3 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/migration.c b/migration.c
index b9e3368..401383c 100644
--- a/migration.c
+++ b/migration.c
@@ -116,6 +116,9 @@ void do_info_migrate(Monitor *mon)
         switch (s->get_status(s)) {
         case MIG_STATE_ACTIVE:
             monitor_printf(mon, "active\n");
+            monitor_printf(mon, "transferred ram: %" PRIu64 " kbytes\n", ram_bytes_transferred() >> 10);
+            monitor_printf(mon, "remaining ram: %" PRIu64 " kbytes\n", ram_bytes_remaining() >> 10);
+            monitor_printf(mon, "total ram: %" PRIu64 " kbytes\n", ram_bytes_total() >> 10);
             break;
         case MIG_STATE_COMPLETED:
             monitor_printf(mon, "completed\n");
diff --git a/sysemu.h b/sysemu.h
index 7d65804..fdf0971 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -28,6 +28,10 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
 void vm_start(void);
 void vm_stop(int reason);
 
+uint64_t ram_bytes_remaining(void);
+uint64_t ram_bytes_transferred(void);
+uint64_t ram_bytes_total(void);
+
 int64_t cpu_get_ticks(void);
 void cpu_enable_ticks(void);
 void cpu_disable_ticks(void);
diff --git a/vl.c b/vl.c
index d84ecef..95c268f 100644
--- a/vl.c
+++ b/vl.c
@@ -3236,6 +3236,7 @@ static int ram_save_block(QEMUFile *f)
 }
 
 static ram_addr_t ram_save_threshold = 10;
+static ram_addr_t bytes_transferred = 0;
 
 static ram_addr_t ram_save_remaining(void)
 {
@@ -3250,6 +3251,21 @@ static ram_addr_t ram_save_remaining(void)
     return count;
 }
 
+uint64_t ram_bytes_remaining(void)
+{
+    return ram_save_remaining() * TARGET_PAGE_SIZE;
+}
+
+uint64_t ram_bytes_transferred(void)
+{
+    return bytes_transferred;
+}
+
+uint64_t ram_bytes_total(void)
+{
+    return last_ram_offset;
+}
+
 static int ram_save_live(QEMUFile *f, int stage, void *opaque)
 {
     ram_addr_t addr;
@@ -3271,6 +3287,7 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
         int ret;
 
         ret = ram_save_block(f);
+        bytes_transferred += ret * TARGET_PAGE_SIZE;
         if (ret == 0) /* no more blocks */
             break;
     }
@@ -3280,7 +3297,9 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
     if (stage == 3) {
 
         /* flush all remaining blocks regardless of rate limiting */
-        while (ram_save_block(f) != 0);
+        while (ram_save_block(f) != 0) {
+            bytes_transferred += TARGET_PAGE_SIZE;
+        }
         cpu_physical_memory_set_dirty_tracking(0);
     }
 
-- 
1.5.6.6

[Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

This patch augments info migrate output with status about:
* pages remaining
* pages transferred

This should be enough for management tools to realize
whether or not there is progress in migration. We can
add more information later on, if the need arrives

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 migration.c |    2 ++
 sysemu.h    |    6 ++++++
 vl.c        |   13 +++++++++++--
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/migration.c b/migration.c
index b9e3368..88d63c0 100644
--- a/migration.c
+++ b/migration.c
@@ -116,6 +116,8 @@ void do_info_migrate(Monitor *mon)
         switch (s->get_status(s)) {
         case MIG_STATE_ACTIVE:
             monitor_printf(mon, "active\n");
+            monitor_printf(mon, "remaining ram pages: %u\n", ram_save_remaining());
+            monitor_printf(mon, "transferred ram pages: %u\n", ram_save_transferred());
             break;
         case MIG_STATE_COMPLETED:
             monitor_printf(mon, "completed\n");
diff --git a/sysemu.h b/sysemu.h
index 7d65804..76ab84b 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -28,6 +28,12 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
 void vm_start(void);
 void vm_stop(int reason);
 
+#ifdef NEED_CPU_H
+#include "cpu-defs.h"
+ram_addr_t ram_save_remaining(void);
+ram_addr_t ram_save_transferred(void);
+#endif
+
 int64_t cpu_get_ticks(void);
 void cpu_enable_ticks(void);
 void cpu_disable_ticks(void);
diff --git a/vl.c b/vl.c
index 9f25cd4..97a1bc6 100644
--- a/vl.c
+++ b/vl.c
@@ -3236,8 +3236,9 @@ static int ram_save_block(QEMUFile *f)
 }
 
 static ram_addr_t ram_save_threshold = 10;
+static ram_addr_t pages_transferred = 0;
 
-static ram_addr_t ram_save_remaining(void)
+ram_addr_t ram_save_remaining(void)
 {
     ram_addr_t addr;
     ram_addr_t count = 0;
@@ -3250,6 +3251,11 @@ static ram_addr_t ram_save_remaining(void)
     return count;
 }
 
+ram_addr_t ram_save_transferred(void)
+{
+    return pages_transferred;
+}
+
 static int ram_save_live(QEMUFile *f, int stage, void *opaque)
 {
     ram_addr_t addr;
@@ -3271,6 +3277,7 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
         int ret;
 
         ret = ram_save_block(f);
+        pages_transferred += ret;
         if (ret == 0) /* no more blocks */
             break;
     }
@@ -3280,7 +3287,9 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
     if (stage == 3) {
 
         /* flush all remaining blocks regardless of rate limiting */
-        while (ram_save_block(f) != 0);
+        while (ram_save_block(f) != 0) {
+            pages_transferred++;
+        }
         cpu_physical_memory_set_dirty_tracking(0);
     }
 
-- 
1.5.6.6

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Dor Laor]

Glauber Costa wrote:
> This patch augments info migrate output with status about:
> * pages remaining
> * pages transferred
>
> This should be enough for management tools to realize
> whether or not there is progress in migration. We can
> add more information later on, if the need arrives
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
>  migration.c |    2 ++
>  sysemu.h    |    6 ++++++
>  vl.c        |   13 +++++++++++--
>  3 files changed, 19 insertions(+), 2 deletions(-)
>
> diff --git a/migration.c b/migration.c
> index b9e3368..88d63c0 100644
> --- a/migration.c
> +++ b/migration.c
> @@ -116,6 +116,8 @@ void do_info_migrate(Monitor *mon)
>          switch (s->get_status(s)) {
>          case MIG_STATE_ACTIVE:
>              monitor_printf(mon, "active\n");
> +            monitor_printf(mon, "remaining ram pages: %u\n", ram_save_remaining());
> +            monitor_printf(mon, "transferred ram pages: %u\n", ram_save_transferred());
>              break;
>          case MIG_STATE_COMPLETED:
>              monitor_printf(mon, "completed\n");
> diff --git a/sysemu.h b/sysemu.h
> index 7d65804..76ab84b 100644
> --- a/sysemu.h
> +++ b/sysemu.h
> @@ -28,6 +28,12 @@ void qemu_del_vm_change_state_handler(VMChangeStateEntry *e);
>  void vm_start(void);
>  void vm_stop(int reason);
>  
> +#ifdef NEED_CPU_H
> +#include "cpu-defs.h"
> +ram_addr_t ram_save_remaining(void);
> +ram_addr_t ram_save_transferred(void);
> +#endif
> +
>  int64_t cpu_get_ticks(void);
>  void cpu_enable_ticks(void);
>  void cpu_disable_ticks(void);
> diff --git a/vl.c b/vl.c
> index 9f25cd4..97a1bc6 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -3236,8 +3236,9 @@ static int ram_save_block(QEMUFile *f)
>  }
>  
>  static ram_addr_t ram_save_threshold = 10;
> +static ram_addr_t pages_transferred = 0;
>   

It would be nice to zero pages_transferred each migration operation.
ram_save_threshold is really to small. From Uri's past measurements, as 
value of 50 is a
better suite. Alternately it can be parametrized by the monitor command.

In general there is small drawback in the current approach:
The way bandwidth is capped,  iirc,  in every second you start consuming 
migration
bandwidth. If the bandwidth allocation was consumed after 100msec, 
you'll wait 900msec.
In this period, mgmt app reading the ram_save_remaining will notice that 
migration does
not progress and might either increase bandwidth or stop the guest.
That's why #of no-progress-iteration has advantage.

>  
> -static ram_addr_t ram_save_remaining(void)
> +ram_addr_t ram_save_remaining(void)
>  {
>      ram_addr_t addr;
>      ram_addr_t count = 0;
> @@ -3250,6 +3251,11 @@ static ram_addr_t ram_save_remaining(void)
>      return count;
>  }
>  
> +ram_addr_t ram_save_transferred(void)
> +{
> +    return pages_transferred;
> +}
> +
>  static int ram_save_live(QEMUFile *f, int stage, void *opaque)
>  {
>      ram_addr_t addr;
> @@ -3271,6 +3277,7 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
>          int ret;
>  
>          ret = ram_save_block(f);
> +        pages_transferred += ret;
>          if (ret == 0) /* no more blocks */
>              break;
>      }
> @@ -3280,7 +3287,9 @@ static int ram_save_live(QEMUFile *f, int stage, void *opaque)
>      if (stage == 3) {
>  
>          /* flush all remaining blocks regardless of rate limiting */
> -        while (ram_save_block(f) != 0);
> +        while (ram_save_block(f) != 0) {
> +            pages_transferred++;
> +        }
>          cpu_physical_memory_set_dirty_tracking(0);
>      }
>  
>   

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Anthony Liguori]

Dor Laor wrote:
>>  static ram_addr_t ram_save_threshold = 10;
>> +static ram_addr_t pages_transferred = 0;
>>   
>
> It would be nice to zero pages_transferred each migration operation.
> ram_save_threshold is really to small. From Uri's past measurements, 
> as value of 50 is a
> better suite. Alternately it can be parametrized by the monitor command.
>
> In general there is small drawback in the current approach:
> The way bandwidth is capped,  iirc,  in every second you start 
> consuming migration
> bandwidth. If the bandwidth allocation was consumed after 100msec, 
> you'll wait 900msec.
> In this period, mgmt app reading the ram_save_remaining will notice 
> that migration does
> not progress and might either increase bandwidth or stop the guest.
> That's why #of no-progress-iteration has advantage.

If I were implementing this in libvirt, here's what I would do:

B = MB/sec bandwidth limit
S = guest size in MB
C = some constant factor, perhaps 4-5

T = S / B * C

1) Wait for T seconds or until migration completes.
2) If timeout occurred:
   a) M = actual transfer rate for migration in MB/sec
   b) If M < B, T1 = S / M * C
   c) T = T1 - T
   d) If T <= 0, migration failed
   d) else goto 1

Basically, this institutes a policy that a migration must complete after 
transferring C * guest_size amount of data.  It adjusts for observed 
bandwidth rate vs. capped.  It makes sense from an administrative 
perspective because you are probably only willing to waste so much 
network bandwidth on attempting to migrate.  Obviously, C and B are 
tunables that heavily depend on the relatively priority of the migration.

Whether you force a non-live migration after failure of a live migration 
is an administrative decision.

-- 
Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

>
> It would be nice to zero pages_transferred each migration operation.
Yeah, that makes sense.

> ram_save_threshold is really to small. From Uri's past measurements, as  
> value of 50 is a
> better suite.
Every value is arbitrary in essence. If after this patches we still see need
to change that, I'd say change it to a percentage of guest total memory,
or even better, the average number of pages that were transferred per iteration

> Alternately it can be parametrized by the monitor command.
With this, I completely disagree. Let us say we switch in the future to a
new migration algorithm that does not rely on any treshold at all. What
should we do with this parameter?

This is totally implementation dependant, and should not be exposed.
the bandwidth is what we want to control externally.

>
> In general there is small drawback in the current approach:
> The way bandwidth is capped,  iirc,  in every second you start consuming  
> migration
> bandwidth. If the bandwidth allocation was consumed after 100msec,  
> you'll wait 900msec.
> In this period, mgmt app reading the ram_save_remaining will notice that  
> migration does
> not progress and might either increase bandwidth or stop the guest.

So what? If one second is too much, have them to use 500ms. Also, if the bandwidth
was consumed after 100 ms and the number of remaining pages _increased_ when mgmt
tool read it again, this is the most genuine case of need for increasing bandwidth
in the whole universe.

Or have them use a better algorithm altogether.
The point is, this is not qemu's problem.

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Avi Kivity]

Glauber Costa wrote:
>> Alternately it can be parametrized by the monitor command.
>>     
> With this, I completely disagree. Let us say we switch in the future to a
> new migration algorithm that does not rely on any treshold at all. What
> should we do with this parameter?
>
> This is totally implementation dependant, and should not be exposed.
> the bandwidth is what we want to control externally.
>   

We want to control bandwidth and application downtime.  Why not specify 
those as parameters?

qemu will live migrate using the specified bandwidth until it reaches a 
page count that allows it to stop the guest and complete migration 
within the allowed downtime.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Daniel P. Berrange]

On Wed, May 20, 2009 at 07:20:05PM -0400, Glauber Costa wrote:
> This patch augments info migrate output with status about:
> * pages remaining
> * pages transferred

Could you add 'pages total' and/or possibly 'page size', so apps 
using this can more easily do calculations, without having to worry
about hardcoding page sizes for each architecture they deal with. 

Oh, what happens if the guest is backed by huge pages ? Does the
'pages transferred' always count in terms of 4k pages, even if
2 M & 1 GB pages are in use ?

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

On Thu, May 21, 2009 at 03:05:04PM +0100, Daniel P. Berrange wrote:
> On Wed, May 20, 2009 at 07:20:05PM -0400, Glauber Costa wrote:
> > This patch augments info migrate output with status about:
> > * pages remaining
> > * pages transferred
> 
> Could you add 'pages total' and/or possibly 'page size', so apps 
> using this can more easily do calculations, without having to worry
> about hardcoding page sizes for each architecture they deal with. 
That can be done.

> 
> Oh, what happens if the guest is backed by huge pages ? Does the
> 'pages transferred' always count in terms of 4k pages, even if
> 2 M & 1 GB pages are in use ?
Right now, IIRC, migration code scan pages in multiples of TARGET_PAGE_SIZE.
we don't have any code path to deal with pages larger than that.

However, I believe it makes sense to be specific that we're talking about
TARGET_PAGE_SIZE pages. In the future, we may then have separate lines
for each kind of page being transferred.

In a nutshell, we can have something in the lines of:
pages total:
  X 4K pages
  Y 2M pages
pages remaining:
  X' 4k pages
  Y' 2M pages
pages transferred:
  X'' 4k pages
  Y'' 2M pages

Of course, 2M would only be shown in this example if we are really using any.

How do you feel about that?

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Avi Kivity]

Daniel P. Berrange wrote:
> On Wed, May 20, 2009 at 07:20:05PM -0400, Glauber Costa wrote:
>   
>> This patch augments info migrate output with status about:
>> * pages remaining
>> * pages transferred
>>     
>
> Could you add 'pages total' and/or possibly 'page size', so apps 
> using this can more easily do calculations, without having to worry
> about hardcoding page sizes for each architecture they deal with. 
>
> Oh, what happens if the guest is backed by huge pages ? Does the
> 'pages transferred' always count in terms of 4k pages, even if
> 2 M & 1 GB pages are in use ?
>   

We should just use bytes.  I don't see how backing page size matters.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Daniel P. Berrange]

On Thu, May 21, 2009 at 05:58:10PM +0300, Avi Kivity wrote:
> Daniel P. Berrange wrote:
> >On Wed, May 20, 2009 at 07:20:05PM -0400, Glauber Costa wrote:
> >  
> >>This patch augments info migrate output with status about:
> >>* pages remaining
> >>* pages transferred
> >>    
> >
> >Could you add 'pages total' and/or possibly 'page size', so apps 
> >using this can more easily do calculations, without having to worry
> >about hardcoding page sizes for each architecture they deal with. 
> >
> >Oh, what happens if the guest is backed by huge pages ? Does the
> >'pages transferred' always count in terms of 4k pages, even if
> >2 M & 1 GB pages are in use ?
> >  
> 
> We should just use bytes.  I don't see how backing page size matters.

That works for me, because ultimately bytes is what I'd want at libvirt
layer. 

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

On Thu, May 21, 2009 at 04:04:57PM +0100, Daniel P. Berrange wrote:
> On Thu, May 21, 2009 at 05:58:10PM +0300, Avi Kivity wrote:
> > Daniel P. Berrange wrote:
> > >On Wed, May 20, 2009 at 07:20:05PM -0400, Glauber Costa wrote:
> > >  
> > >>This patch augments info migrate output with status about:
> > >>* pages remaining
> > >>* pages transferred
> > >>    
> > >
> > >Could you add 'pages total' and/or possibly 'page size', so apps 
> > >using this can more easily do calculations, without having to worry
> > >about hardcoding page sizes for each architecture they deal with. 
> > >
> > >Oh, what happens if the guest is backed by huge pages ? Does the
> > >'pages transferred' always count in terms of 4k pages, even if
> > >2 M & 1 GB pages are in use ?
> > >  
> > 
> > We should just use bytes.  I don't see how backing page size matters.
> 
> That works for me, because ultimately bytes is what I'd want at libvirt
> layer. 
agreed.