|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] CPU and scheduler init in Xen
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>
|
- [Xen-devel] CPU and scheduler init in Xen,
George Dunlap <=
|
|
|
|
|