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] [day] [month] [year] [list]

Message-Id: <200803170144.50990.david-b@pacbell.net>
Date:	Mon, 17 Mar 2008 00:44:49 -0800
From:	David Brownell <david-b@...bell.net>
To:	linux-pm@...ts.linux-foundation.org
Cc:	Alan Stern <stern@...land.harvard.edu>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Chanda Sethia <chanda.sethia@...ibm.com>,
	suresh.b.siddha@...el.com,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	tglx@...utronix.de, discuss@...swatts.org,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [linux-pm] Too many timer interrupts in NO_HZ

On Sunday 16 March 2008, Alan Stern wrote:
> On Sun, 16 Mar 2008, Vaidyanathan Srinivasan wrote:
> 
> The largest entry is for ehci_watchdog.  This timer won't run at all if

... you're not accessing EHCI devices at all.  Is HAL or
something else polling them too often?  Or are you maybe
doing something else that resembles "real work"?


> 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.

That watchdog is a bit messy, but it's got two basic tasks:

 (a) Take work off the async ring ... bulk and control
     transfers will leave an empty QH there for a few
     milliseconds before taking it off, to avoid wasting
     effort in the common case where another transfer
     quickly follows the first one.  In the extreme case,
     when there's no more work, that ring gets disabled.

 (b) A real I/O watchdog ... in case the hardware forgets
     to issue some kind of I/O completion interrupt.  This
     watchdog rarely needs to fire.

So I'm thinking this is most likely a case where something
is sending work to one or more high speed devices.

- Dave

--
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/