Re: [Qemu-devel] Re: [PATCH 22/22] migration: Make state definitions local

[Anthony Liguori]

On 02/24/2011 06:23 AM, Juan Quintela wrote:
> Yoshiaki Tamura<address@hidden>  wrote:
>    
> > 2011/2/23 Juan Quintela<address@hidden>:
> >      
> > > Yoshiaki Tamura<address@hidden>  wrote:
> > >        
> > > > 2011/2/23 Juan Quintela<address@hidden>:
> > > >          
>    
> > > > Although you're right, I would prefer to keep it so that somebody
> > > > outside of migration may understand the status in the future if
> > > > there are no harms.
> > > >          
> > > my plan is to move MigrationState inside migration.c, and then decide
> > > what to export/not export.
> > >        
> > Well, it may be just a policy, but it's already exported, and I
> > would like to keep it unless it bothers your plan.  IIUC, I don't
> > think it does.
> >
> >      
> > > Next thing to do is move migration to its
> > > own thread.  Before doing that, I need to know what parts are used/not
> > > used outside migration.c.  Removing it now means that nothing gets to
> > > use it without needing a patch.
> > >        
> > I've once asked Anthony whether it's possible to make migration
> > to different threads, but his answer was no due to hard
> > dependency of qemu's internal code, and making migration to
> > different threads are bad design.
> >      
> I know.  But Anthony is seeing the light O:-)
>    

Let's be very careful about quoting Anthony as he's known to be 
incoherent 90% of the time :-)

I don't quite recall the context of the discussion with Yoshi, but I'm 
not quite there in terms of advocating that we throw a bucket full of 
threads at migration.  I think we should move the ram migration to 
another I/O thread that doesn't hold a lock against the main I/O 
thread.  That's all.

Regards,

Anthony Liguori

> Basically, without an own thread we are not able to:
> - do anything else while on incoming migration
>    (namely using the monitor)
> - do anything else than migration.  We can try hard and let vcpus to
>    run, but we would still clog the io_thread.
> - We are not able to saturate 10Gbit networking (basically we are doing
>    2/3 level of bufferering (depending on how you count).
>
> So, once code is there, I guess we will convince Anthony to commit it.
>
> Later, Juan.
>
>