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
vcpu_migrate.patch
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
| 
Home