Peter Xu <[email protected]> writes: > Currently, mgmt can only query for remaining RAM,
Remind me: how? > not system-wise remaining > data. It was not a problem before, because for a very long time RAM was > the only part that matters. > > After VFIO migrations landed upstream, it may not be true anymore > especially considering that there can be GPU devices that contain GBs of > device states. > > Add a new "remaining" field in query-migrate results, reflecting > system-wise remaining data, which will include everything (e.g. VFIO). "system-wise"? Do you mean "system-wide"? Maybe "total"? > > This information will be useful for mgmt to implement generic way of stall > detection that covers all system resources. Say, when system remaining > data does not decrease anymore for a relatively long period of time, then > it may mean that there is a challenge of converging, so mgmt can act based > on how this value changes over time (especially if sampled after each > migration iteration). > > Before this patch, "expected_downtime" almost played this role. For > example, by monitoring "expected_downtime" at the beginning of each > iteration can in most cases also reflect the progress of migration > system-wise. Said that, "expected_downtime" was always calculated based on > a bandwidth value that can fluctuate a lot if avail-switchover-bandwidth is > not used. This new "remaining" field will remove that part of uncertainty > for mgmt. > > With the new field, HMP "info migrate" now reports this: > > (qemu) info migrate > Status: active > Time (ms): total=12080, setup=14, exp_down=300 > Remaining: 1.36 GiB <------------------- newline "Newline" is ASCI character '\n'. I guess you mean "this is the new line". > RAM info: > Throughput (Mbps): 840.50 > Sizes: pagesize=4 KiB, total=4.02 GiB > Transfers: transferred=1.18 GiB, remain=1.36 GiB > Channels: precopy=1.18 GiB, multifd=0 B, postcopy=0 B > Page Types: normal=307923, zero=388148 > Page Rates (pps): transfer=25660 > Others: dirty_syncs=1 > > It should be the same value as RAM's remaining report when VFIO is not > involved, and it should report more than that when VFIO is involved. "RAM's remaining report" is the "remain=1.36 GiB" part, isn't it? > Cc: Markus Armbruster <[email protected]> > Reviewed-by: Juraj Marcin <[email protected]> > Reviewed-by: Dr. David Alan Gilbert <[email protected]> > Signed-off-by: Peter Xu <[email protected]> > --- > qapi/migration.json | 4 ++++ > migration/migration-hmp-cmds.c | 5 +++++ > migration/migration.c | 7 +++++++ > 3 files changed, 16 insertions(+) > > diff --git a/qapi/migration.json b/qapi/migration.json > index e3ad3f0604..a6e24b5685 100644 > --- a/qapi/migration.json > +++ b/qapi/migration.json > @@ -300,6 +300,9 @@ > # average memory load of the virtual CPU indirectly. Note that > # zero means guest doesn't dirty memory. (Since 8.1) > # > +# @remaining: amount of bytes remaining to be migrated system-wise, > +# includes both RAM and all devices (like VFIO). (Since 11.1) > +# > # Features: > # > # @unstable: Members @postcopy-latency, @postcopy-vcpu-latency, > @@ -310,6 +313,7 @@ > ## > { 'struct': 'MigrationInfo', > 'data': {'*status': 'MigrationStatus', '*ram': 'MigrationRAMStats', > + '*remaining': 'uint64', It's a byte count, so let's make it 'size'. > '*vfio': 'VfioStats', > '*xbzrle-cache': 'XBZRLECacheStats', > '*total-time': 'int', [...]
