On Fri, 20 Apr 2012, Srivatsa S. Bhat wrote:> > This first part moves the idle thread management for non-boot cpus> > into the core. fork_idle() is called in a workqueue as it is> > implemented in a few architectures already. This is necessary when not> > all cpus are brought up by the early boot code as otherwise we would> > take a ref on the user task VM of the thread which brings the cpu up> > via the sysfs interface.> > > > > Do you have a git tree where you have made these patches available?> That would be pretty useful, so that we can build on whatever you have

Not yet, but I'll stick that into a tip/ branch.

> already done.. Myself and Nikunj had some initial design/ideas on reducing> the duplication in architecture code, related to managing the setting> of the cpu in the online mask, sending out CPU_STARTING notifiers etc> from generic code..

The whole notifier business needs a redesign as well, because we don'thave a way to express proper dependencies, we add random notifierpoints and the teardown path is ass backwards. The whole thing wantsto be a tree which can be walked in either direction and from anypoint. Right now we cut the trunk first and keep the single limb upwith a helicopter and start dismantling it.

Flat notifiers are not working for this as they do not allow a treestructure and prevent us to do things in parallel.

That really needs to be completely reworked. There is also a lot ofstuff which wants to be moved into the starting/dying CPUcontext. Right now we kinda do that by trampling on the CPU with ahigh prio stomper thread, but that's really just a bandaid and steadycause of trouble.

If you look at facilities which use kthreads, then there is lots othersetup which does not need a notifier at all, as it can be done in thecontext of the thread when we have a way to start/park those threadsat the right time in the up/down process.

I've already done a prototype for kthread park/unpark and convertedsoftirq over to use it. That makes the complete softirq notifier goaway and let the core code handle the thread creation / start / park /unpark. It's pretty hacky right now, but I'm going to push on thisnext, once I have a better idea how to express the dependency tree.