Re: parallel suspend/resume

Alan Stern
2007-12-10T17:57:29Z

On Sun, 9 Dec 2007, David Brownell wrote:

> > > FWIW the appended patch removes that rude "order of registration"
> >
> > "Rude"? What's rude about it? It seems most logical to me: Since the
> > devices obviously worked in the intermediate stages of registration,
> > ...
>
> Rude because it keeps things implicit which should be explicit.

Your patch isn't really much better (IMHO). While its order may be
less "random" in the sense that it is determined by the device tree,
the tree itself is somewhat random and not fully determined by the
physical hardware layout. It is affected by the order in which drivers
are loaded, or the order in which PCI cards are probed, and so on.

And in any case, having a fixed order doesn't move us any closer to the
goal of making all the dependencies explicit.

> Such a random visitation seems like a clear problem when a
> goal is to introduce parallelism ...

So does a strict depth-first visitation. Or indeed, any fixed
ordering, since parallelism will involve indeterminacy.

> Nope; what we need is the ability to finger "this specific device
> has dependencies that aren't explicit". Being able to introduce
> random failures isn't really helpful. It's the difference between
> being able to use lockdep vs. having to wait until a random locking
> failure crops up in a way that can usefully be diagnosed.

I agree. Even better would be to say "this specific device has this
specific dependency". But it's not easy to come up with strategies for
finding this information. There's no clear-cut analog to lockdep.

Alan Stern