On Tue, Jun 10, 2025 at 01:53:40PM +0000, Dr. David Alan Gilbert wrote: > * Peter Xu (pet...@redhat.com) wrote: > > On Tue, Jun 10, 2025 at 12:08:23AM +0000, Dr. David Alan Gilbert wrote: > > > > diff --git a/qapi/migration.json b/qapi/migration.json > > > > index 4963f6ca12..e95b7402cb 100644 > > > > --- a/qapi/migration.json > > > > +++ b/qapi/migration.json > > > > @@ -236,6 +236,17 @@ > > > > # This is only present when the postcopy-blocktime migration > > > > # capability is enabled. (Since 3.0) > > > > # > > > > +# @postcopy-latency: average remote page fault latency (in us). Note > > > > that > > > > +# this doesn't include all faults, but only the ones that require a > > > > +# remote page request. So it should be always bigger than the real > > > > +# average page fault latency. This is only present when the > > > > +# postcopy-blocktime migration capability is enabled. (Since 10.1) > > > > +# > > > > +# @postcopy-vcpu-latency: average remote page fault latency per vCPU > > > > (in > > > > +# us). It has the same definition of @postcopy-latency, but > > > > instead > > > > +# this is the per-vCPU statistics. This is only present when the > > > > +# postcopy-blocktime migration capability is enabled. (Since 10.1) > > > > > > I wonder if even 'us' is too big; given you have 64bits to play with, and > > > your > > > examples show some samples landing in under 10us, perhaps it's best > > > to at least define the qapi fields as ns, even if you keep with the same > > > buckets for now? > > > > The few <10us ones should pretty much be outliers, I'd expect it happened > > because some faulted pages got lucky to be migrated (in the background > > stream rather than the preempt stream) right after sending the request. > > > > But it's still a fair point, especially if there's nothing to lose to > > switch to nanoseconds here when we have 64bits fields.. I also did a quick > > check online, looks like RDMA over 100Gbps NIC may actually do a fast > > round-robin transaction within a few microseconds indeed at least with zero > > loads.. > > > > Let me do the switch in v3. > > > > While at it, when thinking of possible future unit/format changes in the > > report, maybe I should also mark all of these fields experimental from the > > start? So we don't necessarily need to maintain the ABI - the expectation > > is even if a mgmt would like to fetch those they should only fetch and dump > > it into log so that human can read later only for debugging purposes. > > Yeh I think that's OK, although perhaps another way would be to add > a field indicating the time of the first bucket; i.e. you could specify > that all the values are in ns, but have first-bucket=1000 to be exactly > the same as you have it now.
Right, that should also be better than the current. Marking experimental could be slightly more flexible though, e.g. once we want to report in other formats other than power-of-two buckets. I'll think about it. Thanks for the input! -- Peter Xu
