On Thu, 31 Jan 2013, Andrew Morton wrote:
> On Thu, 31 Jan 2013 15:44:10 -0000
> Thomas Gleixner <t...@linutronix.de> wrote:
>
> > At the end hotplug should run through an array of callbacks on both
> > sides with explicit core synchronization points. The ordering should
> > look like this:
> >
> > CPUHP_OFFLINE // Start state.
> > CPUHP_PREP_<hardware> // Kick CPU into life / let it die
> > CPUHP_PREP_<datastructures> // Get datastructures set up / freed.
> > CPUHP_PREP_<threads> // Create threads for cpu
> > CPUHP_SYNC // Synchronization point
> > CPUHP_INIT_<hardware> // Startup/teardown on the CPU
> > (interrupts, timers ...)
> > CPUHP_SCHED_<stuff on CPU> // Unpark/park per cpu local threads on the
> > CPU.
> > CPUHP_ENABLE_<stuff_on_CPU> // Enable/disable facilities
> > CPUHP_SYNC // Synchronization point
> > CPUHP_SCHED // Expose/remove CPU from general scheduler.
> > CPUHP_ONLINE // Final state
>
> What does CPUHP_SYNC do?
This is a future step which makes sure that the cpu which controls the
bringup and the teardown of the hotplugged cpu are synchronizing at
some point. Right now, we have this synchronization burried somewhere
in the architecture code and of course every arch does it different
versus the generic bringup/teardown mechanisms.
> Methinks Tejun needed a cc on this lot ;)
Not really. The workqueue hotplug scheme is today one of the sanest in
that area. Earlier versions have been a prime example of hotplug hell!
TJ has converted it via the notifier priorities to a symetric
startup/teardown scheme already. So the conversion is a no brainer and
no real change.
Sure, I should have spent the cycles to add every file owner to the cc
list, but due to brain damage caused by decoding the current hotplug
maze I skipped that painful exercise relying on you to fix it up for
me :)
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
