From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: [PATCH 1/3] qemu-kvm: Wrap phys_ram_dirty with additional inline functions. Date: Mon, 15 Feb 2010 14:05:15 +0900 Message-ID: <4B78D60B.8030309@lab.ntt.co.jp> References: <4B6FE5DA.6000502@lab.ntt.co.jp> <4B73FB39.1000200@redhat.com> <4B74B800.2060006@lab.ntt.co.jp> <4B7655C4.1050507@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: OHMURA Kei , kvm@vger.kernel.org, qemu-devel@nongnu.org, Jan Kiszka , anthony@codemonkey.ws To: Avi Kivity Return-path: Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:35918 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751761Ab0BOFFs (ORCPT ); Mon, 15 Feb 2010 00:05:48 -0500 In-Reply-To: <4B7655C4.1050507@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > 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. Sounds good. If we could extend the packing ratio to kvm (in kernel), it would be more efficient. >> 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. Would be happy to do it. We were also thinking that approach originally, but hesitating because the changes might be radical. I hope this plan is fine for upstream qemu too.