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

From: Rafael J. Wysocki
Date: Sat Dec 19 2009 - 16:40:17 EST

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?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at