Re: [PATCH 0/4] support dirtyrate measurement with dirty bitmap

[Peter Xu <peterx@redhat.com>]

On Sun, Jul 11, 2021 at 11:27:13PM +0800, Hyman Huang wrote:
> > IMHO we can directly do the calculation when synchronizing the dirty bits in
> > below functions:
> > 
> >          cpu_physical_memory_set_dirty_range
> >          cpu_physical_memory_set_dirty_lebitmap
> >          cpu_physical_memory_sync_dirty_bitmap
> > 
> > Maybe we can define a global statistics for that?
> uhhh... Do you mean that we can reuse the DIRTY_MEMORY_MIGRATION dirty bits
> to stat the new dirty pages number and just define the global var to count
> the increased dirty pages during the calculation time?

I think I misguided you.. Sorry :)

cpu_physical_memory_sync_dirty_bitmap() should not really be in the list above,
as it's fetching the bitmap in ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION].

If you see the other two functions, they all apply dirty bits upon the same
bitmap (actually ram_list.dirty_memory[*] instead of migration-only).  It's
used by e.g. memory region log_sync() to deliver lower level dirty bits to
upper, e.g., see kvm's log_sync[_global]() and kvm_slot_sync_dirty_pages().

Using cpu_physical_memory_sync_dirty_bitmap() is not a good idea to me (which I
saw you used in your latest version), as it could affect migration.  See its
only caller now at ramblock_sync_dirty_bitmap(): when migration calls it, it'll
start to count less than it should for rs->migration_dirty_pages.

So what I wanted to suggest is we do some general counting in both
cpu_physical_memory_set_dirty_range and cpu_physical_memory_set_dirty_lebitmap.
Then to sync for dirty rate measuring, we use memory_global_dirty_log_sync().
That'll sync all dirty bits e.g. in kernel to ram_list.dirty_memory[*], along
which we do the accounting.

Would that work?

-- 
Peter Xu