Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.

[Avi Kivity <avi@redhat.com>]

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.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.