On Tue, 15 Dec 2009, Rafael J. Wysocki wrote: > > Ideally we would figure out how to do the slow devices in parallel > > without interference from fast devices having unknown dependencies. > > Unfortunately this may not be possible. > > I really expect to see those "unknown dependencies" in the _noirq > suspend/resume phases and above. [The very fact they exist is worrisome, > because that's why we don't know why things work on one system and don't > work on another, although they appear to be very similar.] This is a good reason for keeping the _noirq phases synchronous. AFAIK they don't take long enough to be worth converting, so there's no loss. > > The real issue is "blockage": synchronous devices preventing > > possible concurrency among async devices. That's what you thought > > making PCI bridges async would help. > > > > In general, blockage arises in suspend when you have an async child > > with a synchronous parent. The parent has to wait for the child, which > > might take a long time, thereby delaying other unrelated devices. > > Exactly, but the Linus' point seems to be that's going to be rare and we > should be able to special case all of the interesting cases. Maybe that's true. Without seeing some examples of actual dpm_list contents, we can't tell. Can you post the interesting parts of the lists from some of your test machines? Maybe with a USB device or two plugged in? (The device names together with the names of their parents should be enough.) > > (This explains why you wanted to make PCI bridges async -- they are the > > parents of USB controllers.) For resume it's the opposite: an async > > parent with synchronous children. > > Is that really going to happen in practice? I mean, what would be the point? I don't know. It's all speculation until we see some actual lists. Alan Stern -- 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
