From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] Avoid endless loop for vcpu migration Date: Tue, 15 Mar 2011 06:50:59 +0100 Message-ID: <4D7EFE43.7070900@ts.fujitsu.com> References: <9d164ce877a75cab847b.1300113594@nehalem1> <4D7E3C640200007800036564@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4D7E3C640200007800036564@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 03/14/11 16:03, Jan Beulich wrote: >>>> On 14.03.11 at 15:39, Juergen Gross 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@ts.fujitsu.com Domagkstr. 28 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html