On Mon, 7 Dec 2009, Rafael J. Wysocki wrote: > > BTW, I still don't quite understand why not to put the parent's down_write > operation into the core. It's not going to hurt for the "synchronous" devices > and the "asynchronous" ones will need to do it anyway. That's what I started out doing (see the first pseudo-code with the two phases). But it _does_ actually hurt. Because it will hurt exactly for the "multiple hubs" case: if you have two USB hubs in parallel (and the case that Alan pointed out about a USB host bridge is the exact same deal), then you want to be able to suspend and resume those two independent hubs in parallel too. But if you do the "down_write()" synchronously in the core, that means that you are also stopping the whole "traverse the tree" thing - so now you aren't handling the hubs in parallel even if you are handling all the devices _behind_ them asynchronously. This "serialize while traversing the tree" was what I was initially trying to avoid with the two-phase approach, but that I realized (after writing the resume path) that I could avoid much better by just moving the parents down_write into the asynchronous path. > Also it looks like that's something to do unconditionally for all nodes > having children, because the parent need not know if the children do async > operations. True, and that was (again) the first iteration. But see above: in order to allow way more concurrency, you don't want to introduce the false dependency between the write-lock and the traversal of the tree (or, as Alan points out - just a list - but that doesn't really change anything) that is introduced by taking the lock synchronously. So by moving the write-lock to the asynchronous work that also shuts down the parent, you avoid that whole unnecessary serialization. But that means that you can't do the lock in generic code. Unless you want to do _all_ of the async logic in generic code and re-introduce the "dev->async_suspend" flag. I would be ok with that now that the infrastructure seems so simple. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
