Messages in this thread | | | Date | Fri, 1 Feb 2013 11:51:16 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: [patch 00/40] CPU hotplug rework - episode I |
| |
On Fri, 1 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 1, 2013 at 9:44 AM, Thomas Gleixner <tglx@linutronix.de> wrote: > > > > Just face it. The current hotplug maze has 100+ states which are > > completely undocumented. They are asymetric vs. startup and > > teardown. They just exists and work somehow aside of the occasional > > hard to decode hickup. > > > > Do you really want to preserve that state by all means [F*ck no]? > > No., But I also don't want to replace it with "there's now eleven > documented states, and random people hook into random documented > states".
That's not the plan.
> So for me it's the "expose these states" that I get worried about.. A > random driver should not necessarily even be able to *see* this, and > decide to be clever and take advantage of the ordering. > > So I'd hope there would be some visibility restrictions. We currently > have drivers already being confused by DOWN_PREPARE vs DOWN_FAILED etc > etc random state transitions, and giving them even more flexibility to > pick random states sounds like a really bad idea. I'd like to make > sure that drivers and filesystems etc do not even *see* the states > that are meant for the scheduler or workqueues, for example).
The only states where drivers, filesystems etc are going to see in the end is:
CPUHP_PREP_<datastructures> // Get datastructures set up / freed.
This is _before_ a cpu comes to life and _after_ it is gone. And that does not require ordering.
CPUHP_ENABLE_<stuff_on_CPU> // Enable/disable facilities
This is _before_ a cpu becomes visible to the general scheduler and _after_ it has been removed from it.
Those states do not require ordering at least not at the driver level.
And they are not going to be exposed with a dozen of substates. The only information at both stages is going to be: setup or teardown.
The enable/disable stuff is not allowed to fail. There is no reason why a driver could veto a cpu offline operation.
The only thing which can fail is the setup stage in preparation, where you could fail to allocate memory etc.
> So 11 states (although some of those seem to have lots of substates, > so there may be many more) is too many to *expose*. It's not > necessarily too many to "have and document", if you see the > difference.
I don't want to expose them to the general public. I just want the (arch) core states documented proper with an explicit ordering scheme. Drivers and stuff should not even know about ordering requirements.
Thanks,
tglx
| |