lkml.org 
[lkml]   [2008]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [linux-pm] Too many timer interrupts in NO_HZ
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



\
 
 \ /
  Last update: 2008-03-17 03:37    [from the cache]
©2003-2011 Jasper Spaans