Re: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)

Rafael J. Wysocki
2009-12-19T21:41:03Z

On Friday 18 December 2009, Alan Stern wrote:
> On Fri, 18 Dec 2009, Rafael J. Wysocki wrote:
>
> > I didn't manage to do that, but I was able to mark sd and i8042 as async and
> > see the impact of this.
>
> Apparently this didn't do what you wanted. In the nx6325
> sd+i8042+async+extra log, the 0:0:0:0 device (which is a SCSI disk) was
> suspended by the main thread instead of an async thread.

Hm, that's odd, because there's a noticeable time difference between the
two cases in which the sd is sync and async. I'll look into it further.

> There's an important point I neglected to mention before. Your logs
> don't show anything for devices with no suspend callbacks at all.
> Nevertheless, these devices sit on the device list and prevent other
> devices from suspending or resuming as soon as they could.

Unless they are async, that is.

> For example, the fingerprint sensor (3-1) took the most time to resume.
> But other devices were delayed until after it finished because it had
> children with no callbacks, and they delayed the devices following
> them in the list.
>
> What would happen if you completed these devices immediately, as part
> of the first pass?

OK. How do the PM core is supposed to check if a device has null suspend
and resume? Check all of the function pointers in the first pass?

Rafael