[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Cpupools and pdata_alloc
On Mon, May 10, 2010 at 11:48 PM, Juergen Gross <juergen.gross@xxxxxxxxxxxxxx> wrote: > No. It happens when idle vcpus are allocated. At this time there is no > cpupool > existing, all physical cpus are marked as "free", e.g. they are in no pool > at > all. > Dom0 vcpus are allocated in Pool-0. This pool is created after allocation of > the idle vcpus. Yeah, I spent some time tracing through the init code yesterday and figured that out. So it appears that at init time, regarding cpupools and schedulers: * init_idle_domain() calls schedule_init(), which calls ops->init() with a sort of "default" ops pointer. It also calls sched_init_vcpu() for idle domain's vcpu 0, which will call ops->alloc_pdata for cpu 0. * smp_prepare_cpus will eventually call do_boot_cpu for each online cpu. do_boot_cpu will initialize the idle_domain vcpu for that cpu, which will call ops->alloc_pdata for that cpu (again, with cpu 0 - At this point, all online cpus have had alloc_pdata called, albeit for the "default" ops structure in the scheduler * cpupool_create will create cpupool 0, calling sched_init(), which calls ops->init with the cpupool0 ops structure. * cpupool0_cpu_assign will then un-assign all online cpus from the "default" ops structure and re-assign them into cpupool 0. Re-assigning looks like this: - First call alloc_pdata and then alloc_vdata for the new cpupool ops structure, for the physical cpu and idle vcpu respectively. - Ticks will be disabled on the old ops structure, then resumed on the new ops structure - The idle vcpu is added to the new pool - Calls free_vdata and free_pdata on the old cpupool ops structure for the idle vcpu and physical cpu, respectively. Now all online cpus have idle vcpus and pdatas initialized, and set up for cpupool 0. Is that a pretty accurate picture? > BTW: Allocating the percpu data of the scheduler during the allocation of > the > first vcpu on this cpu was in sched_credit.c before cpupools were > introduced. Yes, I remember that. IIRC it had something to do with the timer infrastructure not being ready during sched_init, so init_cpu was used as a hook to set up the per-cpu tick after the timer infrastructure had been initialized. Although, looking at the code again, it's more likely that I thought that because when sched_init was called, only one cpu was online. Kier, out of curiosity, is there a reason init_idle_domain() (and thus schedule_init()) is called so early, before all of the cpus are up? Is it so that adding a cpu dynamically and at boot (which needs to do in it, add an idle vcpu, &c) all take the same codepath? > Not yet. > I'll write something up in the next days. Cool, thanks. -George _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |