Avi Kivity <a...@redhat.com> wrote: > On 11/30/2010 04:46 PM, Juan Quintela wrote: >> Anthony Liguori<anth...@codemonkey.ws> wrote: >> > On 11/23/2010 05:03 PM, Juan Quintela wrote: >> >> From: Juan Quintela<quint...@trasno.org> >> >> >> >> Calculate the number of dirty pages takes a lot on hosts with lots >> >> of memory. Just maintain how many pages are dirty. Only sync bitmaps >> >> if number is small enough. >> >> >> > >> > There needs to be numbers that justify this as part of the commit message. >> >> They are on patch 0/6. >> >> Additionally, with 64GB of RAM, this bitmap is HUGE, having to walk over >> it in each ram_save_live() call is too onerous. > > It's not so huge. It's scaled down by a factor of 8 * 4096 = 32K. So > it's a 2MB bitmap. If kept as a bitmap and accessed in longs, it can > be read in less than a millisecond.
Going to undertand why we need the other bitmaps for kvm. Basically we have: - CODE bit: kvm don't care - VGA bit: not really sure how much we care. My understanding is that the bitmap for the VGA don't need to be as big as all memory. - MIGRATION bit: we care O:-) Now, we are setting the MIGRATION in three ways: - kvm (we sync with that) - vhost net: it uses a different mechanism, not shared with kvm - *write[blw]. My understanding is that we care about this ones. Do we really care? We are also syncing too much bitmaps, we can do a bit less syncing. > An optimization can be to look at the previous ram_save_live (which > had to walk the bitmap). If old_nr_dirty > 4*target_nr_dirty, assume > we need one more pass and don't scan the bitmap. We had a similar optimization on rhel5. We only synched the bitmap each time that we passed over address 0. And each time that we called ram_save_remaining(). Trivial optimization for ram_save_reamaining is to: - maintain the number of pages that are dirty (we only modify the bitmap in two places, trivial to inc/dec the total number of dirty pages). - on ram_save_live only sync bitmap if we are about to exit from the loop. If pages dirty are still bigger that the one we need to go to non-save life, it makes no sense to sync. > Another optimization is to stop the count when we reach the target; > instead of ram_save_remaining() have a ram_save_may_stop() which > counts the number of dirty bits until it reaches target_nr_dirty or > exhausts the bitmap. The problem here is that guest want to continue running, and continues dirtying pages. So, no obvious place where to stop counting. Or I am losing something? Later, Juan.
