|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Avoid endless loop for vcpu migration
On 03/15/11 08:57, Jan Beulich wrote: On 15.03.11 at 06:50, Juergen Gross<juergen.gross@xxxxxxxxxxxxxx> wrote: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.You're only decreasing the likelihood of a live lock, as the return value of pick_cpu not only depends on idle_bias. Hmm, then another solution would be to let pick_cpu really return the proposed cpu from the first iteration, if it doesn't contradict the allowed settings. It could be sub-optimal, but I don't think this is critical, as vcpu_migrate is called rarely. Patch attached. 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.It's not critical, and not affecting correctness. But with updating idle_bias on the first invocation you're (on the right hardware) basically guaranteeing the second invocation to return a different CPU. That way, your loop will be run minimally three times on such systems. I already find it odd to require two iterations when previously this was a strait code path. This was wrong. It was always required to hold the schedule lock of the picked cpu as well, otherwise a race with cpu hotplug would be possible. If there's really no way around the iterative approach, one possibility might be to not take into consideration idle_bias on non-initial invocations at all. This would be a side effect of my suggestion. 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 Attachment:
vcpu_migrate.patch _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |