Re: [PATCH v3 00/21] KVM: Dirty ring interface

[Peter Xu]

On Thu, Jan 09, 2020 at 11:40:23AM -0500, Michael S. Tsirkin wrote:

[...]

> > > I know it's mostly relevant for huge VMs, but OTOH these
> > > probably use huge pages.
> > 
> > Yes huge VMs could benefit more, especially if the dirty rate is not
> > that high, I believe.  Though, could you elaborate on why huge pages
> > are special here?
> > 
> > Thanks,
> 
> With hugetlbfs there are less bits to test: e.g. with 2M pages a single
> bit set marks 512 pages as dirty.  We do not take advantage of this
> but it looks like a rather obvious optimization.

Right, but isn't that the trade-off between granularity of dirty
tracking and how easy it is to collect the dirty bits?  Say, it'll be
merely impossible to migrate 1G-huge-page-backed guests if we track
dirty bits using huge page granularity, since each touch of guest
memory will cause another 1G memory to be transferred even if most of
the content is the same.  2M can be somewhere in the middle, but still
the same write amplify issue exists.

PS. that seems to be another topic after all besides the dirty ring
series because we need to change our policy first if we want to track
it with huge pages; with that, for dirty ring we can start to leverage
the kvm_dirty_gfn.pad to store the page size with another new kvm cap
when we really want.

Thanks,

-- 
Peter Xu