Re: [Xen-devel] [PATCH] Avoid endless loop for vcpu migration

[Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>]

On 03/14/11 16:03, Jan Beulich wrote:
> > > > On 14.03.11 at 15:39, Juergen Gross<juergen.gross@xxxxxxxxxxxxxx>  wrote:
> > On multi-thread multi-core systems an endless loop can occur in vcpu_migrate()
> > with credit scheduler. Avoid this loop by changing the interface of pick_cpu
> > to indicate a repeated call in this case.
> But you're not changing in any way the loop that doesn't get
> exited - did you perhaps read my original description as the
> pick function itself looping (which - afaict - it doesn't)?
I'm changing the way the pick_cpu function is reacting on multiple calls in
a loop. If I've understood the idle_bias correctly, updating it in each
loop iteration did result in returning another cpu for each call.
By updating idle_bias only once, it should return the same cpu in subsequent
calls. This should exit the loop in vcpu_migrate.

> Further, the change still isn't consistent with idle_bias - the
> updating ought to happen on the last iteration (if you need
> to call the function more than once), not the first one, which
> creates a chicken-and-egg problem for you as you will know
> it's the last one only when it returned.
Is it really so important idle_bias is reflecting the last cpu selected?
I was under the impression it should be okay when this is true in most
cases. With my patch idle_bias might be "wrong" if there is a race with
other cpus forcing a selection of a different cpu in the second iteration
of the loop in vcpu_migrate. Is this really critical? I doubt it.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel