From: Open Source <opensource3141@yahoo.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: WolfgangMües <wolfgang@iksw-muees.de>,
linux-usb-devel@lists.sourceforge.net,
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:02:40 -0700 (PDT) [thread overview]
Message-ID: <20061013230240.84447.qmail@web58108.mail.re3.yahoo.com> (raw)
Hi Alan,
Yes, user mode processes are susceptible to other delays,
but that's really not the problem here. My application is
*clearly* being hit by this difference in CONFIG_HZ.
All the evidence points to this fact.
People often bring this up user mode versus kernel
mode as a criticism when it doesn't really apply.
All I was saying is that we should get away
from the talk of kernel versus user mode and narrow
the problem to something more specific.
As for the issue regarding ehci_work and ehci_irq:
There are many many comments in the code that say
that urb linking happens asynchronously. It is hard for
me to fully appreciate how everything is put together
because I am not an expert with the host controller code
in the kernel. Is there some way we can get to the bottom of this?
Either the problem is in the ehci code or in devio.c. In
devio.c the user space process calls an ioctl to reap the
urb (blocking until it is complete). The asynchronous
callback for the urb is called when the urb is unlinked
and that callback (async_completed in devio.c) signals
the wait object that the ioctl has added to the wait queue.
But, I don't see anything inherently wrong with how things
are setup there.
In any case, something is wrong. I want to be as helpful
as possible to get to the bottom of this, but it might be tough
to do it without some insight from the gurus who wrote this code.
Even if the problem will be hard to fix, we should have a
clear understanding of what is causing it. As it stands it doesn't
seem like even the experts know exactly where this
delay is being caused.
Thanks.
----- Original Message ----
From: Alan Stern <stern@rowland.harvard.edu>
To: Open Source <opensource3141@yahoo.com>
Cc: WolfgangMües <wolfgang@iksw-muees.de>; linux-usb-devel@lists.sourceforge.net; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 2:08:46 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
On Fri, 13 Oct 2006, Open Source wrote:
> Hi Wolfgang (and all),
>
> Thanks for the input. However, I am not understanding
> exactly why kernel mode is treated any differently than
> user mode for this sort of thing. I am looking at the code
> in ehci-q.c and ehci-hcd.c.
>
> 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. I'm not able to ascertain how
> user mode drivers are treated differently than
> kernel mode drivers in this regard. From what I
> can tell, all drivers would be broken equally!
> Can anyone who has more experience
> with this code confirm this for me?
I don't think so. You must be mis-reading the code. The only timers used
in ehci-hcd are a couple of watchdogs; they shouldn't affect the normal
URB completions which occur within ehci_work(), called by ehci_irq().
What Wolfgang meant was that user processes are subject to unpredictable
delays from all kinds of sources.
Alan Stern
next reply other threads:[~2006-10-13 23:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-13 23:02 Open Source [this message]
2006-10-13 23:41 ` Alan Cox
-- 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 19:31 Open Source
2006-10-13 21:08 ` [linux-usb-devel] " Alan Stern
2006-10-13 23:33 ` David Brownell
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=20061013230240.84447.qmail@web58108.mail.re3.yahoo.com \
--to=opensource3141@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
--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®