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...
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
