On Mon, Dec 26, 2011 at 02:05:20PM +0900, Takuya Yoshikawa wrote:
> From my x86 dirty logging experience I have some concern about your code:
> your code looks slow even when there is no/few dirty pages in the slot.
>
> + for (i = 0; i < memslot->npages; ++i) {
> + if (kvm_test_clear_dirty(kvm, rmapp))
> + __set_bit_le(i, map);
> + ++rmapp;
> + }
>
> The check is being done for each page and this can be very expensive because
> the number of pages is not small.
>
> When we scan the dirty_bitmap 64 pages are checked at once and
> the problem is not so significant.
>
> Though I do not know well what kvm-ppc's dirty logging is aiming at, I guess
> reporting cleanliness without noticeable delay to the user-space is important.
>
> E.g. for VGA most of the cases are clean. For live migration, the
> chance of seeing complete clean slot is small but almost all cases
> are sparse.
The alternative approach is not to use the hardware changed bit but
instead to install read-only HPTEs when the guest requests a
read/write mapping, and then when the guest writes to the page we
intercept the protection fault, mark the page dirty and change the
HPTE to allow writing. Then when harvesting the dirty bits we have to
change any dirty page back to a read-only HPTE.
That is all quite doable, but I was worried about the performance
impact of the extra faults. We intend to do some performance studies
to see whether the alternative approach would give better performance.
There is a trade-off in that the alternative approach would slow down
normal operation a little in order to speed up the harvesting of the
dirty log. That may in fact be worthwhile.
For now, the patch I posted at least gets the dirty page tracking
working, so we can use VGA emulation.
Paul.
--
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
