Re: [PATCH 2/2] kvm: change the dirty page tracking to work with dirty bity

From: Izik Eidus <ieidus@redhat.com>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: kvm@vger.kernel.org, avi@redhat.com
Subject: Re: [PATCH 2/2] kvm: change the dirty page tracking to work with dirty bity
Date: Thu, 11 Jun 2009 18:49:03 +0300	[thread overview]
Message-ID: <4A31276F.3080107@redhat.com> (raw)
In-Reply-To: <20090611122411.GB3944@amt.cnet>

Marcelo Tosatti wrote:
> On Thu, Jun 11, 2009 at 02:27:46PM +0300, Izik Eidus wrote:
>   
>> Marcelo Tosatti wrote:
>>     
>>> What i'm saying is with shadow and NPT (i believe) you can mark a spte
>>> writable but not dirty, which gives you the ability to know whether
>>> certain pages have been dirtied.
>>>   
>>>       
>> Isnt this what this patch is doing?
>>     
>
> Yes, was confused for some reason i don't remember.
>
> So making the dirty bit available to the host is a good idea, but would
> have to check things like faults on out of sync pagetables (where
> the guest dirty bit might be cleared in parallel, maybe its ok but
> not sure), verify transfer of dirty bit when zapping is consistent
> everywhere, etc.
>   

I am looking on the host sptes, not the guest emulated page tables, when 
the guest clean its dirty bit, we dont clean it from the spte, or am i 
wrong?
When we zap the spte, i transfer the dirty bit into the bitmap in case 
of SPTE_DONT_DIRTY...,

But Avi, pointed out that in case of live migration, it might be 
overkill to walk all the sptes in the system, so maybe we want to add 
page fault from the page directory (would be write protected, or if it 
cant be write protected at least notpresent), and then scan only sptes 
that inside this "write protected" page tables...

You have some ideas for this case?

> So it would be nicer to introduce an optimization to the way dirty bit
> info is acquired, then you use that to optimize kvm's dirty log ioctl.
>
> The link with KSM was that you can consult this dirty info, which is
> fast, to know if content of pages has changed. But it maybe useless,
> don't know.
>
>   
It sure can help for ksm as we calc sometimes jhash of the page to know 
if the page content was changed, but i afraid that starting to clean the 
dirty bit that will need tlbflush, plus taking the mmu_lock to walk the 
sptes, maybe will save ksm some cpu, but might hurt kvm, we will have to 
check this...