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 1/1] Xen ARINC 653 Scheduler (updated to add supp

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/1] Xen ARINC 653 Scheduler (updated to add support for CPU pools)
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Thu, 17 Jun 2010 07:02:28 +0200
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Kathy Hadley <Kathy.Hadley@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 16 Jun 2010 22:03:22 -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=1276750910; x=1308286910; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4C19AC64.7090001@xxxxxxxxxxxxxx>|Date:=20 Thu,=2017=20Jun=202010=2007:02:28=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Keir=20Fraser=20<keir.fraser@xxxxxxxxxxxxx> |CC:=20George=20Dunlap=20<George.Dunlap@xxxxxxxxxxxxx>, =20=0D=0A=20Kathy=20Hadley=20<Kathy.Hadley@xxxxxxxxxxxxxx m>,=0D=0A=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xen-devel@ lists.xensource.com>|Subject:=20Re:=20[Xen-devel]=20[PATC H=201/1]=20Xen=20ARINC=20653=20Scheduler=20(updated=20to =20add=0D=0A=20support=20for=20CPU=20pools)|References: =20<C83EB84E.17B17%keir.fraser@xxxxxxxxxxxxx> |In-Reply-To:=20<C83EB84E.17B17%keir.fraser@xxxxxxxxxxxxx >|Content-Transfer-Encoding:=207bit; bh=HiM23gSv5nbSflf0aalMSF0L5BMTslp4Qm+R6140mEs=; b=u7tQHJTeINc0WtGUnI+RwvycXrCIwg3uyxlg9/e9oDwe+5oB16asv176 VsO9pcWXCV1KwYlbzZ8zprY7cDKn1Rw6R9f6JYmFtNZ2d+V6cWoVj+iLW mwP2oY3vOJVOmtOzpF9gYAQjs+Lwq9zR2s/atOVnRt7kkkIUITqXWdKsk 6A/aJZFkjp8W/Tw9ZV702AjhF+pvmoiDwr6n0gDBUPKW1cOT2NIWxRerC KTxwd2F4Xk+W/OAWPHO8cLrj7dbCy;
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=qHYa51tRJ5utykIlrO+Pnj3geMV+viY+Gc7DjMnIOUrdjZaumq2nZKgz 2YPktTsTGA39kv+h7U1UXNartTpOX9GT8Xor6CLbegN+6U/zOMs1GQHlm 5qbp5Kvfa1l2YrY9LcezzHbXsfIvK3aj3F0YDA0Z/miAd41MjFJG0E4iz oab4JLh6nkZ/nf7EMN8+fx/qOEGC1LNRYE+CiedeH03Wp5BwZ/K51zZH9 3D3UDOTIYRdtO1+g3stmlBu5/i7b2;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C83EB84E.17B17%keir.fraser@xxxxxxxxxxxxx>
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: <C83EB84E.17B17%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Iceowl/1.0b1 Icedove/3.0.4
On 06/16/2010 06:20 PM, Keir Fraser wrote:
On 16/06/2010 17:14, "George Dunlap"<George.Dunlap@xxxxxxxxxxxxx>  wrote:

  I actually tried the xmalloc() method first.  I found that when the
.adjust_global function was called, the address of the "ops" data structure
passed to that function was different from the address of the "ops" data
structure when the .init function was called.  I wanted to use .adjust_global
to modify the data structure that was created when the .init function was
called, but I could not figure out a way to get the address of the second
data structure.  Suggestions?

It's been a month or two since I trawled through the cpupools code;
but I seem to recall that .init is called twice -- once for the
"default pool" (cpupool0), and once for an actually in-use pool.
(Juergen, can you correct me if I'm wrong?)  Is it possible that
that's the difference in the pointers that you're seeing?

Oh yes, that was the old behaviour. I took a hatchet to the
scheduler/cpupool interfaces a few weeks ago and now we should only
initialise the scheduler once, unless extra cpupools are manually created.

Keir, what do you think about creating an "idle-scheduler" for the cpus not in
any cpupool? It would only schedule the idle vcpu and could be VERY minimal.
This could reduce the complexity of moving cpus from and to cpupools.

I could try to setup a patch if you support this idea (I'm asking for your
opinion before starting this, as I'm rather busy with other tasks).


Juergen

P.S.: George, you still seem to use my old mail address which isn't valid any
      more...

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