profiling the resume path

[Marcelo Tosatti]

On Sun, Sep 02, 2007 at 01:03:12PM -0400, Marcelo Tosatti wrote:
> On Sun, Sep 02, 2007 at 12:50:03PM +0100, David Woodhouse wrote:
> > On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote:
> > > Note: ohci_pci_resume does msleep 20. 
> > 
> > Hm. It's just waiting for the hardware to settle, right? Do the resume
> > functions for the devices themselves actually have to wait until this is
> > complete, before they can do anything?
> > 
> > It really sounds like we need to decouple suspend/resume of individual
> > hardware devices from the full system suspend. It should be almost
> > completely asynchronous. Why can't I start running userspace after
> > resume, before I've reinitialised the USB thermometer which is plugged
> > in? Why don't we just block access to that particular device until it's
> > complete (and take that device off-line to save power even when the full
> > system isn't suspended).
> 
> You're entirely right, but I'm talking about something else:
> 
> [    0.040909] cpu_idle+0x2e/0x7c -> check_pgt_cache+0xb/0x31
> [    0.000000] check_pgt_cache+0x2f/0x31 -> quicklist_trim+0xe/0xe5
> [    0.040912] cpu_idle+0x4e/0x7c -> default_idle+0x8/0x43
> [    0.233593] do_IRQ+0x45/0xdb -> irq_enter+0xb/0x2d
> [    0.233594] irq_enter+0x22/0x2d -> idle_cpu+0x8/0x1b
> 
> This interrupt scheduled for 233-40ms is what sounds wrong. It should
> just continue to blaze off the EHCI resume path.

... after 20ms have passed, not almost 200.