This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: "Juergen Gross" <juergen.gross@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Avoid endless loop for vcpu migration
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 15 Mar 2011 07:57:17 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 15 Mar 2011 00:57:23 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D7EFE43.7070900@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <9d164ce877a75cab847b.1300113594@nehalem1> <4D7E3C640200007800036564@xxxxxxxxxxxxxxxxxx> <4D7EFE43.7070900@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> 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.


Xen-devel mailing list