Message-ID: <4B74B800.2060006@lab.ntt.co.jp>
Date: Fri, 12 Feb 2010 11:08:00 +0900
From: OHMURA Kei <ohmura.kei@lab.ntt.co.jp>
MIME-Version: 1.0
References: <4B6FE5DA.6000502@lab.ntt.co.jp> <4B73FB39.1000200@redhat.com>
In-Reply-To: <4B73FB39.1000200@redhat.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with
 additional inline functions.
To: Avi Kivity <avi@redhat.com>
Cc: ohmura.kei@lab.ntt.co.jp, kvm@vger.kernel.org, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>

> 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.

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()...