WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Keir Fraser <keir.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Avoid endless loop for vcpu migration
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Tue, 15 Mar 2011 09:53:02 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Tue, 15 Mar 2011 01:53:39 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1300179184; x=1331715184; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=QJxpr+/cBlEHVA3AZX8JP/raOG/M22Wq2rEAjRPr4Xw=; b=Us+tggcwosUPDDgk5hBM5cgANC/Z3/Hvm+8CRI/mrdmjRnXLsVSsjcuj o+XhZv7qjw7b3R0249LIs9GUi2UOCJmwMMjyuAKKi1D1zDV+ZLZnVV/X1 +4xZtcUg7TAfwW18/mgyroQXgT0j2Ofxq5sEUK2hz2z3Q5KjxcCZ0oifc Ig7O7lyMmr5dw1CXXET8J8NwYVltgEjYL9Jo+D3fObenjISW3BXEijz5d Txd7Al8YTipBLpcQK9ia8OyEClJdI;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=q9ac3xRM1b8OgEIb/YejapIqiZeKMNur1mIbls8z51fc/XojSujuIbhk 9PhlsYBPL+acHsyLEaFD0wbA+937yV9Ec+/7jxzqB227cULpsAbxSIKhq bhljhHe13ym9lKk5RXlo0HGEYGj0sD0GHEHw4Rp+DbrKBY2hRK7zCz+dk 2pSLuL5TjCLRLmoWniPMdWmBHHC09bw07sFgH+QzVojKWg6fyP8hEj+rj vpB5cSCwOG2s0GqWaR5I6DILuPksK;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C9A4D8CC.14CBE%keir.xen@xxxxxxxxx>
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>
Organization: Fujitsu Technology Solutions
References: <C9A4D8CC.14CBE%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Iceowl/1.0b1 Icedove/3.0.11
On 03/15/11 09:50, Keir Fraser wrote:
On 15/03/2011 08:46, "Juergen Gross"<juergen.gross@xxxxxxxxxxxxxx>  wrote:

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.

What would that race be? CPU offlining is done in stop_machine context.

Ahh, okay.


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

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