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

[Xen-devel] CPU and scheduler init in Xen

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] CPU and scheduler init in Xen
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Tue, 7 Dec 2010 15:05:21 +0000
Cc: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Tue, 07 Dec 2010 07:18:45 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3PJ36Tw1CJsp5RfkVZT9qwnJ2rmfsjKCOHMw6x0FOdk=; b=eC2uuQmhXUWFeTZWDCcxGUWXQ5mZvwL0QZvooekWA6XjY12oGEQYZjoapWHlpjmYTA 7n05sQnE5TnKN1+KmoHHvoEZdmI0oMfjKSMOlZQvElAA5IgDrRKVJ7ZsN3p2cCDE5TyO B8kscH6FNsxNH0GCTEwphZPRPgOW0qar8vLWU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=cdsgPuUVBvHssI7e8a8elFiQhniAr36VFLtmBf0OjRWnXfe6liDvFvTLQgUEZRj4QR R4V+KuWowgYmAR5JW6y/p52x/jeL38w9rllOWdY+Q3WR6+tHz6y1WG09oWKnyNq91zpp iskDCzeRdQJdsXdSpCrJVi6Ne3y6xmWfgZDr8=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
OK, so next roadblock in my grand plan to have credit2 base its
runqueues on the cpu topology:

The scheduler is initialized before the CPU identification stuff is
done; so at the time the switchable init() stuff is called, *and* at
the time alloc_pdata() is called, the data about the cpu topology is
not ready yet.

As far as I can tell, tracing through the tangled web of init
functions, this is because:
* CPU id stuff needs to be done on the CPU itself (make sense), so it
happens when bringing up CPUs
* Before that, cpu_init() wants to do basic initialization, including
writing the CR3 value from current
* So one of the first things that a CPU does when starting is set
current to idle_vcpu[cpuid]
* So the idle vcpu for that VM needs to be ready before the CPU boots
* So the scheduler info for that VM is initialized on the boot cpu
before the other cpus are brought up.

On the one hand that all makes sense, but on the other hand it seems
really crazy not to have basic info like the CPU topology available to
the scheduler when the data for that CPU is initialized, and have to
either (1) have a third scheduler callback, "cpu actually initialized
now", or (2) resort to hackish tricks to look stuff up later (as the
credit1 scheduler does to set up timers).

I was hoping to be able to rearrange stuff so that when alloc_pdata()
is called, that cpu_to_socket() be ready, but it's not exactly clear
the best way to do that.

Any advice on how to proceed, Keir?

 -George

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

<Prev in Thread] Current Thread [Next in Thread>