On Sat, 5 Dec 2009 18:05:14 -0800 (PST) Linus Torvalds wrote: > > > On Sun, 6 Dec 2009, Rafael J. Wysocki wrote: > > > > While the current settings are probably unsafe (like enabling PCI > > devices to be suspended asynchronously by default if there are not > > any direct dependences between them), there are provisions to make > > eveything safe, if we have enough information (which also is needed > > to put the required logic into the drivers). > > I disagree. > > Think of a situation that we already handle pretty poorly: USB mass > storage devices over a suspend/resume. > > > The device tree represents a good deal of the dependences > > between devices and the other dependences may be represented as PM > > links enforcing specific ordering of the PM callbacks. > > The device tree means nothing at all, because it may need to be > entirely rebuilt at resume time. btw I instrumented both the suspend and resume, and made graphs out of it for my laptop (modern laptop with Intel cpu/wifi/graphics of course). http://www.fenrus.org/graphs/suspend.svg http://www.fenrus.org/graphs/resume.svg (also attached for convenience) the resume clearly shows that all this talking about PCI stuff is completely without practical merit.. it's the USB stuff where the time is spent. in suspend, there's a PCI device (:1b) that does take some time, which is the audio controller. The bulk of the time is in the serio driver though.. As an "interested bystander" to this thread.... sounds like Linus' arguments have merit, and that solving the USB resume to go async in some form will fix pretty much all we want solving... [and that at least we need to do this stuff data/measurement driven, and not just based on how we THINK things work] -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org