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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> 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.

>> 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.

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.

Jan


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