LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-pm@lists.linux-foundation.org
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
	Chanda Sethia <chanda.sethia@in.ibm.com>,
	suresh.b.siddha@intel.com,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	tglx@linutronix.de, discuss@lesswatts.org,
	Ingo Molnar <mingo@elte.hu>,
	Arjan van de Ven <arjan@infradead.org>
Subject: Re: [linux-pm] Too many timer interrupts in NO_HZ
Date: Mon, 17 Mar 2008 00:44:49 -0800	[thread overview]
Message-ID: <200803170144.50990.david-b@pacbell.net> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0803162224460.2108-100000@netrider.rowland.org>

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


      reply	other threads:[~2008-03-17  8:45 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
2008-03-17  2:34   ` [linux-pm] " Alan Stern
2008-03-17  8:44     ` David Brownell [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=200803170144.50990.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=arjan@infradead.org \
    --cc=chanda.sethia@in.ibm.com \
    --cc=discuss@lesswatts.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=mingo@elte.hu \
    --cc=stern@rowland.harvard.edu \
    --cc=suresh.b.siddha@intel.com \
    --cc=svaidy@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --subject='Re: [linux-pm] Too many timer interrupts in NO_HZ' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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