From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NgCVg-0005Qe-SM for qemu-devel@nongnu.org; Sat, 13 Feb 2010 02:33:48 -0500 Received: from [199.232.76.173] (port=45739 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NgCVg-0005QI-5r for qemu-devel@nongnu.org; Sat, 13 Feb 2010 02:33:48 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NgCVf-00045c-CC for qemu-devel@nongnu.org; Sat, 13 Feb 2010 02:33:48 -0500 Received: from mx20.gnu.org ([199.232.41.8]:1889) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NgCVe-00045V-Og for qemu-devel@nongnu.org; Sat, 13 Feb 2010 02:33:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NgCVd-0006eI-MS for qemu-devel@nongnu.org; Sat, 13 Feb 2010 02:33:45 -0500 Message-ID: <4B7655C4.1050507@redhat.com> Date: Sat, 13 Feb 2010 09:33:24 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4B6FE5DA.6000502@lab.ntt.co.jp> <4B73FB39.1000200@redhat.com> <4B74B800.2060006@lab.ntt.co.jp> In-Reply-To: <4B74B800.2060006@lab.ntt.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: OHMURA Kei Cc: Jan Kiszka , qemu-devel@nongnu.org, kvm@vger.kernel.org, Yoshiaki Tamura 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.