LKML Archive on
help / color / mirror / Atom feed
From: Vaidyanathan Srinivasan <>
	Linux-pm mailing list <>,
	Linux Kernel <>,
	Dipankar Sarma <>, Ingo Molnar <>,,,
	Arjan van de Ven <>,, Gautham R Shenoy <>,
	Chanda Sethia <>
Subject: Re: Too many timer interrupts in NO_HZ
Date: Sun, 16 Mar 2008 23:47:11 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Vaidyanathan Srinivasan <> [2008-03-03 01:18:13]:

> 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()?

> Please help me to understand the following scenario:
> * What can happen in timer interrupt context that need not wakeup any
>   process?
> * What can prevent tick_nohz_stop_sched_tick() from actually stopping
>   the tick?  
> * Whats wrong in expecting to see some of the CPUs having tickless
>   idle time of few minutes

I think I have the answers to some of the above questions.  

Function        Count                   Name

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 roughly the list of functions that were responsible for the
timer interrupts across all cpus including the ones in idle.  Most of
the functions complete the job in interrupt context and also re-queue
the timer.  The count number is the call count in the 120s observation
window across all 4 CPUs.

I got these function addresses from __next_timer_interrupt() in
timer.c.  Previously, I did not look in timer.c since hrtimers were
enabled and I assumed all timer call will be through __run_hrtimer
from hrtimer.c.  The call count of __run_hrtimer was very minimal and
did not correspond to the local timer interrupt count.

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.  

I will post more results after tweaking some of the above timers.

Should PowerTop include local timer interrupt counts as well during
the observation period?  Interrupt do significantly affect CPU sleep
time whether they wakeup any process or not.



  parent reply	other threads:[~2008-03-16 18:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-02 19:48 Vaidyanathan Srinivasan
2008-03-02 19:57 ` Arjan van de Ven
2008-03-02 20:25   ` Vaidyanathan Srinivasan
2008-03-05 15:38   ` Vaidyanathan Srinivasan
2008-03-16 18:17 ` Vaidyanathan Srinivasan [this message]
2008-03-17  2:34   ` [linux-pm] " Alan Stern
2008-03-17  8:44     ` David Brownell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: Too many timer interrupts in NO_HZ' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).