qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 42/51] ram: Pass RAMBlock to bitmap_sync


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH 42/51] ram: Pass RAMBlock to bitmap_sync
Date: Tue, 28 Mar 2017 20:45:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

"Dr. David Alan Gilbert" <address@hidden> wrote:
> * Juan Quintela (address@hidden) wrote:
>> Yang Hongyang <address@hidden> wrote:
>> > On 2017/3/24 4:45, Juan Quintela wrote:
>> >> We change the meaning of start to be the offset from the beggining of
>> >> the block.
>> >> 
>> >> @@ -701,7 +701,7 @@ static void migration_bitmap_sync(RAMState *rs)
>> >>      qemu_mutex_lock(&rs->bitmap_mutex);
>> >>      rcu_read_lock();
>> >>      QLIST_FOREACH_RCU(block, &ram_list.blocks, next) {
>> >> -        migration_bitmap_sync_range(rs, block->offset, 
>> >> block->used_length);
>> >> +        migration_bitmap_sync_range(rs, block, 0, block->used_length);
>> If you have several terabytes of RAM that is too ineficient, because
>> when we arrive to the page_send(page), it is possible that it is already
>> dirty again, and we have to send it twice.  So, the idea is to change to
>> something like:
>> 
>> while(true) {
>>             foreach(block)
>>                 bitmap_sync(block)
>>             foreach(block)
>>                 foreach(64pages)
>>                     bitmap_sync(64pages)
>>                     foreach(page of the 64)
>>                        if (dirty)
>>                           page_send(page)
>
> Yes, although it might be best to actually do the sync in a separate thread
> so that the sync is always a bit ahead of the thread doing the writing.

Doing it synchronously shouldn't be a problem.  But we should be able to
in smaller chucks.

Thanks, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]