Re: [Xen-devel] [RFC PATCH 2/3] xen: Refactor migration

[Juergen Gross <jgross@xxxxxxxx>]

On 11/04/18 14:25, George Dunlap wrote:
> The current sequence to initiate vcpu migration is inefficent and error-prone:
> 
> - The initiator sets VPF_migraging with the lock held, then drops the
>   lock and calls vcpu_sleep_nosync(), which immediately grabs the lock
>   again
> 
> - A number of places unnecessarily check for v->pause_flags in between
>   those two
> 
> - Every call to vcpu_migrate() must be prefaced with
>   vcpu_sleep_nosync() or introduce a race condition; this code
>   duplication is error-prone
> 
> - In the event that v->is_running is true at the beginning of
>   vcpu_migrate(), it's almost certain that vcpu_migrate() will end up
>   being called in context_switch() as well; we might as well simply
>   let it run there and save the duplicated effort (which will be
>   non-negligible).
> 
> Instead, introduce vcpu_migrate_start() to initiate the process.
> vcpu_migrate_start() is called with the scheduling lock held.  It not
> only sets VPF_migrating, but also calls vcpu_sleep_nosync_locked()
> (which will automatically do nothing if there's nothing to do).
> 
> Rename vcpu_migrate() to vcpu_migrate_finish().  Check for v->is_running and
> pause_flags & VPF_migrating at the top and return if appropriate.
> 
> Then the way to initiate migration is consistently:
> 
> * Grab lock
> * vcpu_migrate_start()
> * Release lock
> * vcpu_migrate_finish()
> 
> Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>

Release-acked-by: Juergen Gross <jgross@xxxxxxxx>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel