[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with addition

From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions.
Date: Sat, 13 Feb 2010 09:33:24 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]