On 2/14/2012 11:57 AM, Srivatsa S. Bhat wrote: >> In addition to this, the reality is that the whole "bring cpus up" >> sequence needs to be changed; the current one is very messy and requires >> the hotplug lock for the whole bring up of each individual cpu... which >> is a very unfortunate design; a much better design would be to only take >> the lock for the actual registration of the newly brought up CPU to the >> kernel, while running the physical bringup without the global lock. >> If/when that change gets made, we can do the physical bring up in >> parallel (with each other, but also with the rest of the kernel boot), >> and do the registration en-mass at some convenient time in the boot, >> potentially late. >> > > > Sounds like a good idea, but how will we take care of CPU_UP_PREPARE and > CPU_STARTING callbacks then? Because, CPU_UP_PREPARE callbacks are run > before bringing up the cpu and CPU_STARTING is called from the cpu that is > coming up. Also, CPU_UP_PREPARE callbacks can be failed, which can lead > to that particular cpu boot getting aborted. With the "late commissioning > of CPUs" idea you proposed above, retaining such semantics could become > very challenging.
some of these callbacks may need to be redesigned as well; or at least, we may need to decouple the "physical" state of the CPU that's getting brought up from the "logical" OS visible one. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
