Re: [linux-pm] Too many timer interrupts in NO_HZ

From: Alan Stern
Date: Sun Mar 16 2008 - 22:34:55 EST


On Sun, 16 Mar 2008, Vaidyanathan Srinivasan wrote:

> > The problem:
> >
> > There are way too many timer interrupts even though the CPUs have
> > entered tickless idle loop. Timer interrupts basically bring the CPU
> > out of idle, and then return to tickless idle. There are very few
> > try_to_wake_up()s or need_resched() in between the timer interrupts.
> >
> > What can happen in an idle system in the timer interrupt context that
> > does not invoke a need_resched() or try_to_wake_up()?

> Function Count Name
> Address
>
> c0219922 : 5 blk_unplug_timeout
> c014f464 : 55 wb_timer_fn
> c02b2e67 : 350 bnx2_timer
> c03efcbc : 115 neigh_periodic_timer
> c012894a : 220 process_timeout
> c027d1c4 : 2 hangcheck_fire
> c03fe232 : 3 peer_check_expire
> c012e830 : 25 delayed_work_timer_fn
> c03afe92 : 2783 ehci_watchdog
> c03f1a35 : 10 neigh_timer_handler
> c01d7456 : 110 commit_timeout
> c04381e9 : 2 addrconf_verify
> c03f6d39 : 365 dev_watchdog
> c04126bc : 114 tcp_write_timer

> These are device driver timers that we need to investigate. We should
> try to migrate them to CPU0 (or some other package) to get really long
> uninterrupted CPU sleep time.

The largest entry is for ehci_watchdog. This timer won't run at all if
your EHCI controllers are allowed to autosuspend, which will happen
automatically if

(1) You enable CONFIG_USB_SUSPEND, and

(2) You have no high-speed USB devices attached, or the
ones that are attached have all been suspended.

On the other hand, if you were actively using some high-speed USB
device during the test then it's understandable that there should be
lots of timer interrupts as a result.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/