[Qemu-devel] Re: [PATCH 10/10] Maintaing number of dirty pages

[Juan Quintela]

Avi Kivity <address@hidden> wrote:
> On 11/30/2010 04:46 PM, Juan Quintela wrote:
>> Anthony Liguori<address@hidden>  wrote:
>> >  On 11/23/2010 05:03 PM, Juan Quintela wrote:
>> >>  From: Juan Quintela<address@hidden>
>> >>
>> >>  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.