lkml.org 
[lkml]   [2009]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Async suspend-resume patch w/ completions (was: Re: Async suspend-resume patch w/ rwsems)
Date
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


\
 
 \ /
  Last update: 2009-12-19 22:43    [W:0.149 / U:0.956 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site