On Wed, Feb 07, 2024 at 12:37:15 +0800, Peter Xu wrote: > On Wed, Feb 07, 2024 at 12:13:10PM +0800, Peter Xu wrote: > > On Tue, Feb 06, 2024 at 11:19:04PM +0000, Hao Xiang wrote: > > > This change extends the MigrationStatus interface to track zero pages > > > and zero bytes counter. > > > > > > Signed-off-by: Hao Xiang <hao.xi...@bytedance.com> > > > > Reviewed-by: Peter Xu <pet...@redhat.com> > > I'll need to scratch this, sorry.. > > The issue is I forgot we have "duplicate" which is exactly "zero > page"s.. See: > > info->ram->duplicate = stat64_get(&mig_stats.zero_pages); > > If you think the name too confusing and want a replacement, maybe it's fine > and maybe we can do that. Then we can keep this zero page counter > introduced, reporting the same value as duplicates, then with a follow up > patch to deprecate "duplicate" parameter. See an exmaple on how to > deprecate in 7b24d326348e1672. > > One thing I'm not sure is whether Libvirt will be fine on losing > "duplicates" after 2+ QEMU major releases. Copy Jiri for this. My > understanding is that Libvirt should be keeping an eye on deprecation list > and react, but I'd like to double check..
This should not be a big deal as we can internally map either one (depending on what QEMU supports) to the same libvirt's field. AFAIK there is a consensus on Cc-ing libvirt-devel on patches that deprecate QEMU interfaces so that we can update our code in time before the deprecated interface is dropped. BTW, libvirt maps "duplicate" to: /** * VIR_DOMAIN_JOB_MEMORY_CONSTANT: * * virDomainGetJobStats field: number of pages filled with a constant * byte (all bytes in a single page are identical) transferred since the * beginning of the migration job, as VIR_TYPED_PARAM_ULLONG. * * The most common example of such pages are zero pages, i.e., pages filled * with zero bytes. * * Since: 1.0.3 */ # define VIR_DOMAIN_JOB_MEMORY_CONSTANT "memory_constant" Jirka
