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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.0803162224460.2108-100000@netrider.rowland.org>
Date:	Sun, 16 Mar 2008 22:34:10 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>
cc:	discuss@...sWatts.org,
	Linux-pm mailing list <linux-pm@...ts.linux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>, <venkatesh.pallipadi@...el.com>,
	<tglx@...utronix.de>, Arjan van de Ven <arjan@...radead.org>,
	<suresh.b.siddha@...el.com>, Gautham R Shenoy <ego@...ibm.com>,
	Chanda Sethia <chanda.sethia@...ibm.com>
Subject: Re: [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

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