profiling the resume path

[Marcelo Tosatti]

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.