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

2018-04-26 Thread Juergen Gross
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

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

2018-04-17 Thread Olaf Hering
Am Tue, 17 Apr 2018 09:20:33 +0200 schrieb Dario Faggioli : > And I guess we can add a 'Tested-by: Olaf Hering', as he actually did > that, what do you say Olaf? Yes, that is true. I have tested these three patches with staging. Tested-by: Olaf Hering Olaf

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

2018-04-17 Thread Dario Faggioli
On Wed, 2018-04-11 at 13:25 +0100, 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

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

2018-04-11 Thread George Dunlap
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