From mboxrd@z Thu Jan  1 00:00:00 1970
From: OHMURA Kei <ohmura.kei@lab.ntt.co.jp>
Subject: Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline
 functions.
Date: Fri, 12 Feb 2010 11:08:00 +0900
Message-ID: <4B74B800.2060006@lab.ntt.co.jp>
References: <4B6FE5DA.6000502@lab.ntt.co.jp> <4B73FB39.1000200@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	Jan Kiszka <jan.kiszka@siemens.com>, anthony@codemonkey.ws,
	Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>,
	ohmura.kei@lab.ntt.co.jp
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:46860 "EHLO
	tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1756961Ab0BLCIV (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 11 Feb 2010 21:08:21 -0500
In-Reply-To: <4B73FB39.1000200@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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