[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping fre
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages |
Date: |
Thu, 24 Mar 2016 10:23:55 +0000 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
* Li, Liang Z (address@hidden) wrote:
> > * Wei Yang (address@hidden) wrote:
> > > On Wed, Mar 23, 2016 at 06:48:22AM +0000, Li, Liang Z wrote:
> > > [...]
> > > >> > 8. Pseudo code
> > > >> > Dirty page logging should be enabled before getting the free page
> > > >> > information from guest, this is important because during the
> > > >> > process of getting free pages, some free pages may be used and
> > > >> > written by the guest, dirty page logging can trace these pages.
> > > >> > The pseudo codeĀ is like below:
> > > >> >
> > > >> > -----------------------------------------------
> > > >> > MigrationState *s = migrate_get_current();
> > > >> > ...
> > > >> >
> > > >> > memory_global_dirty_log_start();
> > > >> >
> > > >> > if (get_guest_mem_info(&info)) {
> > > >> > while (!get_free_page_bmap(free_page_bitmap,
> > > >> > drop_page_cache)
> > > >> &&
> > > >> > s->state != MIGRATION_STATUS_CANCELLING) {
> > > >> > usleep(1000) // sleep for 1 ms
> > > >> > }
> > > >> >
> > > >> > tighten_free_page_bmap =
> > > >> tighten_guest_free_pages(free_page_bitmap);
> > > >> > filter_out_guest_free_pages(tighten_free_page_bmap);
> > > >> > }
> > > >>
> > > >> Given the typical speed of networks; it wouldn't do too much harm
> > > >> to start sending assuming all pages are dirty and then when the
> > > >> guest finally gets around to finishing the bitmap then update, so
> > > >> it's asynchronous - and then if the guest never responds we don't
> > > >> really
> > care.
> > > >
> > > >Indeed, thanks!
> > > >
> > >
> > > This is interesting. By doing so, the threshold I mentioned in another
> > > mail is not necessary, since we can do it in parallel.
> >
> > Actually I just realised it's a little more complex; we can't sync the dirty
> > bitmap again from the guest until after we've received the guests 'free'
> > bitmap; that's because we wouldn't know if a 'dirty' page reflected that a
> > page declared as 'free' had now been reused - so there is still an ordering
> > there.
> >
> > Dave
>
> Not very complex, we can implement like this:
>
> 1. Set all the bits in the migration_bitmap_rcu->bmap to 1
> 2. Clear all the bits in ram_list. dirty_memory[DIRTY_MEMORY_MIGRATION]
> 3. Send the get_free_page_bitmap request
> 4. Start to send pages to destination and check if the free_page_bitmap is
> ready
> if (is_ready) {
> filter out the free pages from migration_bitmap_rcu->bmap;
> migration_bitmap_sync();
> }
> continue until live migration complete.
>
>
> Is that right?
The order I'm trying to understand is something like:
a) Send the get_free_page_bitmap request
b) Start sending pages
c) Reach the end of memory
[ is_ready is false - guest hasn't made free map yet ]
d) normal migration_bitmap_sync() at end of first pass
e) Carry on sending dirty pages
f) is_ready is true
f.1) filter out free pages?
f.2) migration_bitmap_sync()
It's f.1 I'm worried about. If the guest started generating the
free bitmap before (d), then a page marked as 'free' in f.1
might have become dirty before (d) and so (f.2) doesn't set
the dirty again, and so we can't filter out pages in f.1.
Dave
>
> Liang
> >
> > >
> > > >Liang
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, (continued)
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Michael S. Tsirkin, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Paolo Bonzini, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Dr. David Alan Gilbert, 2016/03/22
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/23
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Wei Yang, 2016/03/23
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Dr. David Alan Gilbert, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Michael S. Tsirkin, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Michael S. Tsirkin, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Michael S. Tsirkin, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Dr. David Alan Gilbert, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Michael S. Tsirkin, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24
- Re: [Qemu-devel] [RFC Design Doc]Speed up live migration by skipping free pages, Li, Liang Z, 2016/03/24