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
| ||
|
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/
Powered by blists - more mailing lists