lkml.org 
[lkml]   [2020]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 12/21] KVM: X86: Implement ring-based dirty memory tracking
On Thu, Jan 09, 2020 at 02:21:16PM -0500, Peter Xu wrote:
> On Thu, Jan 09, 2020 at 09:56:10AM -0700, Alex Williamson wrote:
>
> [...]
>
> > > > +Dirty GFNs (Guest Frame Numbers) are stored in the dirty_gfns array.
> > > > +For each of the dirty entry it's defined as:
> > > > +
> > > > +struct kvm_dirty_gfn {
> > > > + __u32 pad;
> > >
> > > How about sticking a length here?
> > > This way huge pages can be dirtied in one go.
> >
> > Not just huge pages, but any contiguous range of dirty pages could be
> > reported far more concisely. Thanks,
>
> I replied in the other thread on why I thought KVM might not suite
> that (while vfio may).
>
> Actually we can even do that for KVM as long as we keep a per-vcpu
> last-dirtied GFN range cache (so we don't publish a dirty GFN right
> after it's dirtied), then we grow that cached dirtied range as long as
> the continuous next/previous page is dirtied. If we found that the
> current dirty GFN is not continuous to the cached range, we publish
> the cached range and let the new GFN be the starting of last-dirtied
> GFN range cache.
>
> However I am not sure how much we'll gain from it. Maybe we can do
> that when we have a real use case for it. For now I'm not sure
> whether it would worth the effort.
>
> Thanks,

I agree for the implementation but I think UAPI should support that
from ground up so we don't need to support two kinds of formats.

> --
> Peter Xu

\
 
 \ /
  Last update: 2020-01-09 20:38    [W:0.095 / U:4.840 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site