Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755399AbYCQCeV (ORCPT ); Sun, 16 Mar 2008 22:34:21 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752156AbYCQCeM (ORCPT ); Sun, 16 Mar 2008 22:34:12 -0400 Received: from netrider.rowland.org ([192.131.102.5]:4546 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751625AbYCQCeL (ORCPT ); Sun, 16 Mar 2008 22:34:11 -0400 Date: Sun, 16 Mar 2008 22:34:10 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Vaidyanathan Srinivasan cc: discuss@LessWatts.org, Linux-pm mailing list , Linux Kernel , Dipankar Sarma , Ingo Molnar , , , Arjan van de Ven , , Gautham R Shenoy , Chanda Sethia Subject: Re: [linux-pm] Too many timer interrupts in NO_HZ In-Reply-To: <20080316181711.GK18923@dirshya.in.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2054 Lines: 54 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/