* [Qemu-devel] [PATCH v3 0/1] migration: calculate expected_downtime with ram_bytes_remaining()
@ 2018-04-25 7:10 Balamuruhan S
2018-04-25 7:10 ` [Qemu-devel] [PATCH v3 1/1] " Balamuruhan S
0 siblings, 1 reply; 6+ messages in thread
From: Balamuruhan S @ 2018-04-25 7:10 UTC (permalink / raw)
To: qemu-devel; +Cc: quintela, dgilbert, dgibson, Balamuruhan S
V3:
* commit message to be updated with the changes done by the patch since
v1, review comment by David Gibson.
* Included Michael Roth as ``Reported-by:`` for bringing up the concern.
v2:
There is some difference in expected_downtime value due to following
reason,
1. bandwidth and expected_downtime value are calculated in
migration_update_counters() during each iteration from
migration_thread()
2. remaining ram is calculated in qmp_query_migrate() when we actually
call "info migrate"
This v2 patch where bandwidth, expected_downtime and remaining ram are
calculated in migration_update_counters(), retrieve the same value
during
"info migrate". By this approach we get almost close enough value,
(qemu) info migrate
globals:
store-global-state: on
only-migratable: off
send-configuration: on
send-section-footer: on
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off
zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off
release-ram: off block: off return-path: off pause-before-switchover:
off x-multifd: off dirty-bitmaps: off
Migration status: active
total time: 319737 milliseconds
expected downtime: 1054 milliseconds
setup: 16 milliseconds
transferred ram: 3669862 kbytes
throughput: 108.92 mbps
remaining ram: 14016 kbytes
total ram: 8388864 kbytes
duplicate: 2296276 pages
skipped: 0 pages
normal: 910639 pages
normal bytes: 3642556 kbytes
dirty sync count: 249
page size: 4 kbytes
dirty pages rate: 4626 pages
Calculation:
calculated value = (14016 * 8 ) / 108.92 = 1029.452809401 milliseconds
actual value = 1054 milliseconds
since v1:
use ram_bytes_remaining() instead of dirty_pages_rate * page_size to
calculate expected_downtime to be more accurate.
Regards,
Bala
Balamuruhan S (1):
migration: calculate expected_downtime with ram_bytes_remaining()
migration/migration.c | 11 ++++++++---
migration/migration.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
--
2.14.3
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()
2018-04-25 7:10 [Qemu-devel] [PATCH v3 0/1] migration: calculate expected_downtime with ram_bytes_remaining() Balamuruhan S
@ 2018-04-25 7:10 ` Balamuruhan S
2018-05-01 14:37 ` Balamuruhan S
0 siblings, 1 reply; 6+ messages in thread
From: Balamuruhan S @ 2018-04-25 7:10 UTC (permalink / raw)
To: qemu-devel; +Cc: quintela, dgilbert, dgibson, Balamuruhan S
expected_downtime value is not accurate with dirty_pages_rate * page_size,
using ram_bytes_remaining would yeild it correct. It will initially be a
gross over-estimate, but for for non-converging migrations it should
approach a reasonable estimate later on.
currently bandwidth and expected_downtime value are calculated in
migration_update_counters() during each iteration from
migration_thread(), where as remaining ram is calculated in
qmp_query_migrate() when we actually call "info migrate". Due to this
there is some difference in expected_downtime value being calculated.
with this patch bandwidth, expected_downtime and remaining ram are
calculated in migration_update_counters(), retrieve the same value during
"info migrate". By this approach we get almost close enough value.
Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
---
migration/migration.c | 11 ++++++++---
migration/migration.h | 1 +
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 52a5092add..5d721ee481 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, MigrationState *s)
}
if (s->state != MIGRATION_STATUS_COMPLETED) {
- info->ram->remaining = ram_bytes_remaining();
+ info->ram->remaining = s->ram_bytes_remaining;
info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
}
}
@@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
time_spent = current_time - s->iteration_start_time;
bandwidth = (double)transferred / time_spent;
+ s->ram_bytes_remaining = ram_bytes_remaining();
s->threshold_size = bandwidth * s->parameters.downtime_limit;
s->mbps = (((double) transferred * 8.0) /
@@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
* recalculate. 10000 is a small enough number for our purposes
*/
if (ram_counters.dirty_pages_rate && transferred > 10000) {
- s->expected_downtime = ram_counters.dirty_pages_rate *
- qemu_target_page_size() / bandwidth;
+ /*
+ * It will initially be a gross over-estimate, but for for
+ * non-converging migrations it should approach a reasonable estimate
+ * later on
+ */
+ s->expected_downtime = s->ram_bytes_remaining / bandwidth;
}
qemu_file_reset_rate_limit(s->to_dst_file);
diff --git a/migration/migration.h b/migration/migration.h
index 8d2f320c48..8584f8e22e 100644
--- a/migration/migration.h
+++ b/migration/migration.h
@@ -128,6 +128,7 @@ struct MigrationState
int64_t downtime_start;
int64_t downtime;
int64_t expected_downtime;
+ int64_t ram_bytes_remaining;
bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
int64_t setup_time;
/*
--
2.14.3
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()
2018-04-25 7:10 ` [Qemu-devel] [PATCH v3 1/1] " Balamuruhan S
@ 2018-05-01 14:37 ` Balamuruhan S
2018-05-16 13:43 ` Laurent Vivier
0 siblings, 1 reply; 6+ messages in thread
From: Balamuruhan S @ 2018-05-01 14:37 UTC (permalink / raw)
To: dgilbert, quintela, david; +Cc: qemu-devel
Hi,
Dave, David and Juan if you guys are okay with the patch, please
help to merge it.
Thanks,
Bala
On Wed, Apr 25, 2018 at 12:40:40PM +0530, Balamuruhan S wrote:
> expected_downtime value is not accurate with dirty_pages_rate * page_size,
> using ram_bytes_remaining would yeild it correct. It will initially be a
> gross over-estimate, but for for non-converging migrations it should
> approach a reasonable estimate later on.
>
> currently bandwidth and expected_downtime value are calculated in
> migration_update_counters() during each iteration from
> migration_thread(), where as remaining ram is calculated in
> qmp_query_migrate() when we actually call "info migrate". Due to this
> there is some difference in expected_downtime value being calculated.
>
> with this patch bandwidth, expected_downtime and remaining ram are
> calculated in migration_update_counters(), retrieve the same value during
> "info migrate". By this approach we get almost close enough value.
>
> Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
> ---
> migration/migration.c | 11 ++++++++---
> migration/migration.h | 1 +
> 2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 52a5092add..5d721ee481 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, MigrationState *s)
> }
>
> if (s->state != MIGRATION_STATUS_COMPLETED) {
> - info->ram->remaining = ram_bytes_remaining();
> + info->ram->remaining = s->ram_bytes_remaining;
> info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
> }
> }
> @@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
> transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
> time_spent = current_time - s->iteration_start_time;
> bandwidth = (double)transferred / time_spent;
> + s->ram_bytes_remaining = ram_bytes_remaining();
> s->threshold_size = bandwidth * s->parameters.downtime_limit;
>
> s->mbps = (((double) transferred * 8.0) /
> @@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
> * recalculate. 10000 is a small enough number for our purposes
> */
> if (ram_counters.dirty_pages_rate && transferred > 10000) {
> - s->expected_downtime = ram_counters.dirty_pages_rate *
> - qemu_target_page_size() / bandwidth;
> + /*
> + * It will initially be a gross over-estimate, but for for
> + * non-converging migrations it should approach a reasonable estimate
> + * later on
> + */
> + s->expected_downtime = s->ram_bytes_remaining / bandwidth;
> }
>
> qemu_file_reset_rate_limit(s->to_dst_file);
> diff --git a/migration/migration.h b/migration/migration.h
> index 8d2f320c48..8584f8e22e 100644
> --- a/migration/migration.h
> +++ b/migration/migration.h
> @@ -128,6 +128,7 @@ struct MigrationState
> int64_t downtime_start;
> int64_t downtime;
> int64_t expected_downtime;
> + int64_t ram_bytes_remaining;
> bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
> int64_t setup_time;
> /*
> --
> 2.14.3
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()
2018-05-01 14:37 ` Balamuruhan S
@ 2018-05-16 13:43 ` Laurent Vivier
2018-05-22 11:33 ` Balamuruhan S
2018-06-08 18:24 ` Laurent Vivier
0 siblings, 2 replies; 6+ messages in thread
From: Laurent Vivier @ 2018-05-16 13:43 UTC (permalink / raw)
To: Balamuruhan S, dgilbert, quintela, david; +Cc: qemu-devel
Hi Bala,
I've tested you patch migrating a pseries between a P9 host and a P8
host with 1G huge page size on the P9 side and 16MB on P8 side and the
information are strange now.
"remaining ram" doesn't change, and after a while it can be set to "0"
and estimated downtime is 0 too, but the migration is not completed and
"transferred ram" continues to increase.
so think there is a problem somewhere...
thanks,
Laurent
On 01/05/2018 16:37, Balamuruhan S wrote:
> Hi,
>
> Dave, David and Juan if you guys are okay with the patch, please
> help to merge it.
>
> Thanks,
> Bala
>
> On Wed, Apr 25, 2018 at 12:40:40PM +0530, Balamuruhan S wrote:
>> expected_downtime value is not accurate with dirty_pages_rate * page_size,
>> using ram_bytes_remaining would yeild it correct. It will initially be a
>> gross over-estimate, but for for non-converging migrations it should
>> approach a reasonable estimate later on.
>>
>> currently bandwidth and expected_downtime value are calculated in
>> migration_update_counters() during each iteration from
>> migration_thread(), where as remaining ram is calculated in
>> qmp_query_migrate() when we actually call "info migrate". Due to this
>> there is some difference in expected_downtime value being calculated.
>>
>> with this patch bandwidth, expected_downtime and remaining ram are
>> calculated in migration_update_counters(), retrieve the same value during
>> "info migrate". By this approach we get almost close enough value.
>>
>> Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
>> Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
>> ---
>> migration/migration.c | 11 ++++++++---
>> migration/migration.h | 1 +
>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/migration/migration.c b/migration/migration.c
>> index 52a5092add..5d721ee481 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, MigrationState *s)
>> }
>>
>> if (s->state != MIGRATION_STATUS_COMPLETED) {
>> - info->ram->remaining = ram_bytes_remaining();
>> + info->ram->remaining = s->ram_bytes_remaining;
>> info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
>> }
>> }
>> @@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
>> transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
>> time_spent = current_time - s->iteration_start_time;
>> bandwidth = (double)transferred / time_spent;
>> + s->ram_bytes_remaining = ram_bytes_remaining();
>> s->threshold_size = bandwidth * s->parameters.downtime_limit;
>>
>> s->mbps = (((double) transferred * 8.0) /
>> @@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
>> * recalculate. 10000 is a small enough number for our purposes
>> */
>> if (ram_counters.dirty_pages_rate && transferred > 10000) {
>> - s->expected_downtime = ram_counters.dirty_pages_rate *
>> - qemu_target_page_size() / bandwidth;
>> + /*
>> + * It will initially be a gross over-estimate, but for for
>> + * non-converging migrations it should approach a reasonable estimate
>> + * later on
>> + */
>> + s->expected_downtime = s->ram_bytes_remaining / bandwidth;
>> }
>>
>> qemu_file_reset_rate_limit(s->to_dst_file);
>> diff --git a/migration/migration.h b/migration/migration.h
>> index 8d2f320c48..8584f8e22e 100644
>> --- a/migration/migration.h
>> +++ b/migration/migration.h
>> @@ -128,6 +128,7 @@ struct MigrationState
>> int64_t downtime_start;
>> int64_t downtime;
>> int64_t expected_downtime;
>> + int64_t ram_bytes_remaining;
>> bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
>> int64_t setup_time;
>> /*
>> --
>> 2.14.3
>>
>>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()
2018-05-16 13:43 ` Laurent Vivier
@ 2018-05-22 11:33 ` Balamuruhan S
2018-06-08 18:24 ` Laurent Vivier
1 sibling, 0 replies; 6+ messages in thread
From: Balamuruhan S @ 2018-05-22 11:33 UTC (permalink / raw)
To: Laurent Vivier; +Cc: qemu-devel
On Wed, May 16, 2018 at 03:43:48PM +0200, Laurent Vivier wrote:
> Hi Bala,
>
> I've tested you patch migrating a pseries between a P9 host and a P8
> host with 1G huge page size on the P9 side and 16MB on P8 side and the
> information are strange now.
Hi Laurent,
Thank you for testing the patch,
I too have worked on recreate the same setup and my observation is that
remaining ram is reducing where as expected_downtime remains to be same
as 300 which is same as downtime-limit because, it gets assigned in
migrate_fd_connect() as 300,
s->expected_downtime = s->parameters.downtime_limit;
expected_downtime is not calculated immediately after migration is
started, it takes time to calculate expected_downtime even without this patch
because of the condition in migration_update_counters(),
/*
* if we haven't sent anything, we don't want to
* recalculate. 10000 is a small enough number for our purposes
*/
if (ram_counters.dirty_pages_rate && transferred > 10000) {
calculate expected_downtime
}
> "remaining ram" doesn't change, and after a while it can be set to "0"
> and estimated downtime is 0 too, but the migration is not completed and
I see remaining ram reduces continuously to a point and bumps up again.
migration completes successfully after setting downtime-limit same as
expected_dowtime which is calculated after it enters the condition
mentioned above,
Tested with this patch,
(qemu) info migrate
globals:
store-global-state: on
only-migratable: off
send-configuration: on
send-section-footer: on
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off dirty-bitmaps: off postcopy-blocktime: off
Migration status: active
total time: 50753 milliseconds
expected downtime: 46710 milliseconds
setup: 15 milliseconds
transferred ram: 582332 kbytes
throughput: 95.33 mbps
remaining ram: 543552 kbytes
total ram: 8388864 kbytes
duplicate: 1983194 pages
skipped: 0 pages
normal: 140950 pages
normal bytes: 563800 kbytes
dirty sync count: 2
page size: 4 kbytes
dirty pages rate: 49351 pages
(qemu) migrate_set_parameter downtime-limit 46710
(qemu) info migrate
globals:
store-global-state: on
only-migratable: off
send-configuration: on
send-section-footer: on
capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off postcopy-ram: off x-colo: off release-ram: off block: off return-path: off pause-before-switchover: off x-multifd: off dirty-bitmaps: off postcopy-blocktime: off
Migration status: completed
total time: 118389 milliseconds
downtime: 20324 milliseconds
setup: 15 milliseconds
transferred ram: 1355349 kbytes
throughput: 94.07 mbps
remaining ram: 0 kbytes
total ram: 8388864 kbytes
duplicate: 2139396 pages
skipped: 0 pages
normal: 333485 pages
normal bytes: 1333940 kbytes
dirty sync count: 6
page size: 4 kbytes
> "transferred ram" continues to increase.
If we do not set the downtime-limit, the remaining ram and transferred
ram gets bumped up and migration continues infinitely.
-- Bala
>
> so think there is a problem somewhere...
>
> thanks,
> Laurent
>
> On 01/05/2018 16:37, Balamuruhan S wrote:
> > Hi,
> >
> > Dave, David and Juan if you guys are okay with the patch, please
> > help to merge it.
> >
> > Thanks,
> > Bala
> >
> > On Wed, Apr 25, 2018 at 12:40:40PM +0530, Balamuruhan S wrote:
> >> expected_downtime value is not accurate with dirty_pages_rate * page_size,
> >> using ram_bytes_remaining would yeild it correct. It will initially be a
> >> gross over-estimate, but for for non-converging migrations it should
> >> approach a reasonable estimate later on.
> >>
> >> currently bandwidth and expected_downtime value are calculated in
> >> migration_update_counters() during each iteration from
> >> migration_thread(), where as remaining ram is calculated in
> >> qmp_query_migrate() when we actually call "info migrate". Due to this
> >> there is some difference in expected_downtime value being calculated.
> >>
> >> with this patch bandwidth, expected_downtime and remaining ram are
> >> calculated in migration_update_counters(), retrieve the same value during
> >> "info migrate". By this approach we get almost close enough value.
> >>
> >> Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
> >> Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
> >> ---
> >> migration/migration.c | 11 ++++++++---
> >> migration/migration.h | 1 +
> >> 2 files changed, 9 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/migration/migration.c b/migration/migration.c
> >> index 52a5092add..5d721ee481 100644
> >> --- a/migration/migration.c
> >> +++ b/migration/migration.c
> >> @@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, MigrationState *s)
> >> }
> >>
> >> if (s->state != MIGRATION_STATUS_COMPLETED) {
> >> - info->ram->remaining = ram_bytes_remaining();
> >> + info->ram->remaining = s->ram_bytes_remaining;
> >> info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
> >> }
> >> }
> >> @@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
> >> transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
> >> time_spent = current_time - s->iteration_start_time;
> >> bandwidth = (double)transferred / time_spent;
> >> + s->ram_bytes_remaining = ram_bytes_remaining();
> >> s->threshold_size = bandwidth * s->parameters.downtime_limit;
> >>
> >> s->mbps = (((double) transferred * 8.0) /
> >> @@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
> >> * recalculate. 10000 is a small enough number for our purposes
> >> */
> >> if (ram_counters.dirty_pages_rate && transferred > 10000) {
> >> - s->expected_downtime = ram_counters.dirty_pages_rate *
> >> - qemu_target_page_size() / bandwidth;
> >> + /*
> >> + * It will initially be a gross over-estimate, but for for
> >> + * non-converging migrations it should approach a reasonable estimate
> >> + * later on
> >> + */
> >> + s->expected_downtime = s->ram_bytes_remaining / bandwidth;
> >> }
> >>
> >> qemu_file_reset_rate_limit(s->to_dst_file);
> >> diff --git a/migration/migration.h b/migration/migration.h
> >> index 8d2f320c48..8584f8e22e 100644
> >> --- a/migration/migration.h
> >> +++ b/migration/migration.h
> >> @@ -128,6 +128,7 @@ struct MigrationState
> >> int64_t downtime_start;
> >> int64_t downtime;
> >> int64_t expected_downtime;
> >> + int64_t ram_bytes_remaining;
> >> bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
> >> int64_t setup_time;
> >> /*
> >> --
> >> 2.14.3
> >>
> >>
> >
> >
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Qemu-devel] [PATCH v3 1/1] migration: calculate expected_downtime with ram_bytes_remaining()
2018-05-16 13:43 ` Laurent Vivier
2018-05-22 11:33 ` Balamuruhan S
@ 2018-06-08 18:24 ` Laurent Vivier
1 sibling, 0 replies; 6+ messages in thread
From: Laurent Vivier @ 2018-06-08 18:24 UTC (permalink / raw)
To: Balamuruhan S, dgilbert, quintela, david; +Cc: qemu-devel
Hi,
I had time to investigate more on this problem.
On 16/05/2018 15:43, Laurent Vivier wrote:
> Hi Bala,
>
> I've tested you patch migrating a pseries between a P9 host and a P8
> host with 1G huge page size on the P9 side and 16MB on P8 side and the
> information are strange now.
>
> "remaining ram" doesn't change, and after a while it can be set to "0"
> and estimated downtime is 0 too, but the migration is not completed and
> "transferred ram" continues to increase.
>
> so think there is a problem somewhere...
>
> thanks,
> Laurent
>
> On 01/05/2018 16:37, Balamuruhan S wrote:
>> Hi,
>>
>> Dave, David and Juan if you guys are okay with the patch, please
>> help to merge it.
>>
>> Thanks,
>> Bala
>>
>> On Wed, Apr 25, 2018 at 12:40:40PM +0530, Balamuruhan S wrote:
>>> expected_downtime value is not accurate with dirty_pages_rate * page_size,
>>> using ram_bytes_remaining would yeild it correct. It will initially be a
>>> gross over-estimate, but for for non-converging migrations it should
>>> approach a reasonable estimate later on.
>>>
>>> currently bandwidth and expected_downtime value are calculated in
>>> migration_update_counters() during each iteration from
>>> migration_thread(), where as remaining ram is calculated in
>>> qmp_query_migrate() when we actually call "info migrate". Due to this
>>> there is some difference in expected_downtime value being calculated.
>>>
>>> with this patch bandwidth, expected_downtime and remaining ram are
>>> calculated in migration_update_counters(), retrieve the same value during
>>> "info migrate". By this approach we get almost close enough value.
>>>
>>> Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com>
>>> Signed-off-by: Balamuruhan S <bala24@linux.vnet.ibm.com>
>>> ---
>>> migration/migration.c | 11 ++++++++---
>>> migration/migration.h | 1 +
>>> 2 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/migration/migration.c b/migration/migration.c
>>> index 52a5092add..5d721ee481 100644
>>> --- a/migration/migration.c
>>> +++ b/migration/migration.c
>>> @@ -614,7 +614,7 @@ static void populate_ram_info(MigrationInfo *info, MigrationState *s)
>>> }
>>>
>>> if (s->state != MIGRATION_STATUS_COMPLETED) {
>>> - info->ram->remaining = ram_bytes_remaining();
>>> + info->ram->remaining = s->ram_bytes_remaining;
Don't remove the ram_byte_remaining(), it is updated more often, and
give a better information about the state of memory.
(this why in my test case I have a "remaining" ram" freezed)
>>> info->ram->dirty_pages_rate = ram_counters.dirty_pages_rate;
>>> }
>>> }
>>> @@ -2227,6 +2227,7 @@ static void migration_update_counters(MigrationState *s,
>>> transferred = qemu_ftell(s->to_dst_file) - s->iteration_initial_bytes;
>>> time_spent = current_time - s->iteration_start_time;
>>> bandwidth = (double)transferred / time_spent;
>>> + s->ram_bytes_remaining = ram_bytes_remaining();
>>> s->threshold_size = bandwidth * s->parameters.downtime_limit;
To have an accurate value, we must read the remaining ram just after
having updated the dirty pages count, so I think after
migration_bitmap_sync_range() in migration_bitmap_sync()
>>>
>>> s->mbps = (((double) transferred * 8.0) /
>>> @@ -2237,8 +2238,12 @@ static void migration_update_counters(MigrationState *s,
>>> * recalculate. 10000 is a small enough number for our purposes
>>> */
>>> if (ram_counters.dirty_pages_rate && transferred > 10000) {
>>> - s->expected_downtime = ram_counters.dirty_pages_rate *
>>> - qemu_target_page_size() / bandwidth;
>>> + /*
>>> + * It will initially be a gross over-estimate, but for for
>>> + * non-converging migrations it should approach a reasonable estimate
>>> + * later on
>>> + */
>>> + s->expected_downtime = s->ram_bytes_remaining / bandwidth;
>>> }
>>>
>>> qemu_file_reset_rate_limit(s->to_dst_file);
>>> diff --git a/migration/migration.h b/migration/migration.h
>>> index 8d2f320c48..8584f8e22e 100644
>>> --- a/migration/migration.h
>>> +++ b/migration/migration.h
>>> @@ -128,6 +128,7 @@ struct MigrationState
>>> int64_t downtime_start;
>>> int64_t downtime;
>>> int64_t expected_downtime;
>>> + int64_t ram_bytes_remaining;
>>> bool enabled_capabilities[MIGRATION_CAPABILITY__MAX];
>>> int64_t setup_time;
>>> /*
>>> --
I think you don't need to add ram_byte_remaining, there is in
ram_counters a "remaining" field that seems unused.
I think this fix can be as simple as:
diff --git a/migration/migration.c b/migration/migration.c
index 1e99ec9..25b26f3 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2712,14 +2712,7 @@ static void
migration_update_counters(MigrationState *s,
s->mbps = (((double) transferred * 8.0) /
((double) time_spent / 1000.0)) / 1000.0 / 1000.0;
- /*
- * if we haven't sent anything, we don't want to
- * recalculate. 10000 is a small enough number for our purposes
- */
- if (ram_counters.dirty_pages_rate && transferred > 10000) {
- s->expected_downtime = ram_counters.dirty_pages_rate *
- qemu_target_page_size() / bandwidth;
- }
+ s->expected_downtime = ram_counters.remaining / bandwidth;
qemu_file_reset_rate_limit(s->to_dst_file);
diff --git a/migration/ram.c b/migration/ram.c
index a500015..5f7b9f1 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1164,6 +1164,7 @@ static void migration_bitmap_sync(RAMState *rs)
trace_migration_bitmap_sync_end(rs->num_dirty_pages_period);
+ ram_counters.remaining = ram_bytes_remaining();
end_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
/* more than 1 second = 1000 millisecons */
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-06-08 18:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-04-25 7:10 [Qemu-devel] [PATCH v3 0/1] migration: calculate expected_downtime with ram_bytes_remaining() Balamuruhan S
2018-04-25 7:10 ` [Qemu-devel] [PATCH v3 1/1] " Balamuruhan S
2018-05-01 14:37 ` Balamuruhan S
2018-05-16 13:43 ` Laurent Vivier
2018-05-22 11:33 ` Balamuruhan S
2018-06-08 18:24 ` Laurent Vivier
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).