On 02/12/2010 04:08 AM, OHMURA Kei wrote:
Why do you need a counter? It may be sufficient to set a single bit.
This reduces the memory overhead and perhaps cache thrashing.
Thanks for looking into this. I agree with your opinion.
Our motivation here is to skip traveling when the dirty bitmap is
really sparse
or dense, so either setting a bit or counting up would be fine.
There is one advantage to the counter approach that we can make this
large
traveling granularity flexible. In case of the bit approach, the maximum
granularity is limited to HOST_LONG_BITS. If you think this
flexibility is to
be useless, we would take the bit approach.
The bit approach can be used for any packing ratio; for example you can
pack 64 pages in a single bit. The rule is that if one or more pages is
dirty, the bit is set; otherwise it is clear. This makes clearing a
single page expensive (you have to examine the state of 63 other pages)
but IIRC we always clear in ranges, so apart from the edges, you can use
a memset.
By the way, this is about filling the gap of the dirty bitmap management
between kvm and qemu. Do you think we should set a bit when qemu's
phys_ram_dirty is 0xff or !0?
Radically, if we could have a bit-based phys_ram_dirty_by_word, we may
just OR
the dirty bitmap of kvm with qemu in kvm_get_dirty_pages_log_range()...
The problem is that the qemu uses the dirty information for at least
three different purposes: live migration, vga updates, and tcg
self-modifying code. But I think that's solvable: keep a separate bitmap
for each purpose, and OR the kvm bitmap into any used qemu bitmap
whenever we get it from the kernel.
That has many advantages; foremost, when vnc is not connected and we
aren't live migrating, we can drop all of the bitmaps and save some
memory. If you can make that work I think that's best.