Re: [PATCH v3 4/7] migration/dirtyrate: add per-vcpu option for calc-dirty-rate

From: Peter Xu <peterx@redhat.com>
To: Hyman Huang <huangy81@chinatelecom.cn>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Juan Quintela <quintela@redhat.com>,
	qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3 4/7] migration/dirtyrate: add per-vcpu option for calc-dirty-rate
Date: Mon, 7 Jun 2021 13:13:24 -0400	[thread overview]
Message-ID: <YL5TtDPZdpSQhmZ+@t490s> (raw)
In-Reply-To: <5ce0a796-f261-6a13-1dc9-27bc52ba033d@chinatelecom.cn>

On Tue, Jun 08, 2021 at 12:16:03AM +0800, Hyman Huang wrote:

[...]

> > Actually I'm also wondering whether dirty log could be anything useful here in
> > the future as a 3rd mode (then the "*mode" idea should be more useful if so),
> > basically for old kernels where dirty ring is not there, we can timely call
> > memory_global_dirty_log_sync() and calculate dirty pages there just like what
> > we do with dirty rings (without calling migration_bitmap_sync(), so we don't
> > need to deliver dirty bits from kvmslots to ramblocks, just pick them up from
> > kvm and do the accounting for pure dirty rate measurement).  That's a wild idea
> > though, so just raise it up.  Would that be anything useful?
> uh, actually this idea is what i'm working on to stat the memory heat(trying
> to reduce the transferred memory in migration), theoretically it can be used
> for dirty rate measurement also, maybe i could try it after this patchset
> work having done.

Yes, definitely no need to do that in this series; it just proves that "*mode"
parameter is better in case a 3rd one could come.  Thanks,

-- 
Peter Xu