Messages in this thread | | | Date | Tue, 15 Dec 2009 17:01:18 -0500 (EST) | From | Alan Stern <> | Subject | Re: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems) |
| |
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
| |