On Wed, Aug 11, 2021 at 3:20 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
> On 11/08/21 00:56, Oliver Upton wrote:
> > What if the statistic was 'dirtied_pages', which records the number of
> > pages dirtied in the lifetime of a VM? Userspace could just record the
> > value each time it blows away the dirty bitmaps and subtract that
> > value next time it reads the stat. It would circumvent the need to
> > walk the entire dirty bitmap to keep the statistic sane.
>
> Yeah, that'd be much better also because the "number of dirty pages"
> statistic is not well defined in init-all-dirty mode.
>
> Making it a vCPU stat works in fact, because mark_page_dirty_in_slot is
> only called with kvm_get_running_vcpu() != NULL; see
> kvm_dirty_ring_get() in virt/kvm/dirty_ring.c.
>
> >>
> >> + if (kvm->dirty_ring_size) {
> >> kvm_dirty_ring_push(kvm_dirty_ring_get(kvm),
> >> slot, rel_gfn);
> >> - else
> >> + } else {
> >> set_bit_le(rel_gfn, memslot->dirty_bitmap);
> >> + ++kvm->stat.generic.dirty_pages;
> >> + }
> >
> > Aren't pages being pushed out to the dirty ring just as dirty?
> >
>
> Yes, they are.
>
> Paolo
>
According to Oliver's idea, let's define the "dirty_pages" as the
number of dirtied pages during the life cycle of a VM to avoid the
overhead caused by walking the entire dirty_bitmap.
I didn't consider the dirty ring in this patch, but will do in the next.
Will still define dirty_pages as a VM scoped stat in the next patch.
>From there, we will see if it is necessary to define it as a VCPU
scoped stat. (Both KVM code and user code would be simpler with it
being as a VM scoped stat).
Thanks,
Jing
