From: David Brownell <david-b@pacbell.net>
To: linux-usb-devel@lists.sourceforge.net
Cc: "Open Source" <opensource3141@yahoo.com>,
WolfgangMües <wolfgang@iksw-muees.de>,
linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
Date: Fri, 13 Oct 2006 16:33:03 -0700 [thread overview]
Message-ID: <200610131633.03809.david-b@pacbell.net> (raw)
In-Reply-To: <20061013193107.43500.qmail@web58109.mail.re3.yahoo.com>
On Friday 13 October 2006 12:31 pm, Open Source wrote:
>
> It seems like the unlinking of completed URBs
> happens asynchronously on a timer. This is a
> surprise to me since I thought this was happening
> on an IRQ from the host controller. But if what I'm
> surmising is correct it would explain everything
> I am seeing.
You didn't say what EHCI controller you're using.
The original reason for that timer was specifically
to handle bugs in VIA silicon: that won't always issue
all of the IRQs it's supposed to. Specifically the IAA
IRQ would never arrive, leading to unlink operations
wedging.
Later on that timer got overloaded (and hence it got
to be a bit of a mess) with two other tasks:
(a) deducing that an endpoint had been idle long enough
to take off the ring of active control/bulk queues,
which is what ensures that an idle controller isn't
wasting memory bandwidth by doing DMA all the time.
(It turns out to be a Bad Idea to take idle endpoints
off that ring the instant they become idle, since they
will as a rule be reused very quickly ... so immediate
removal slows things down a lot. Plus it chases an
annoying number of races between driver and controller.)
(b) being a general I/O watchdog, since there were some
other (rare) cases where IRQs would appear to get lost
In short, except for (a) the only reason I know of
that changing HZ should affect system performance is
IRQ lossage ... of which the primary reason has always
been strange behavior from VIA controllers.
- Dave
next prev parent reply other threads:[~2006-10-13 23:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-13 19:31 Open Source
2006-10-13 21:08 ` [linux-usb-devel] " Alan Stern
2006-10-13 23:33 ` David Brownell [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-10-18 23:35 Open Source
2006-10-14 0:24 Alan Cox
2006-10-14 2:11 ` [linux-usb-devel] " Alan Stern
2006-10-13 23:02 Open Source
2006-10-13 23:41 ` Alan Cox
2006-10-13 17:20 Open Source
2006-10-13 18:02 ` Alan Stern
2006-10-13 20:24 ` Bob Copeland
2006-10-12 19:33 Open Source
2006-10-13 13:56 ` [linux-usb-devel] " Alan Stern
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=200610131633.03809.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=opensource3141@yahoo.com \
--cc=wolfgang@iksw-muees.de \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®