Hi,
On Tue, Sep 07, 2004 at 10:00:24PM -0400, [EMAIL PROTECTED] wrote:
> Message: 15
> Date: Tue, 7 Sep 2004 23:16:59 +0100
> From: Colin J Thomson <[EMAIL PROTECTED]>
> Subject: Re: [ck] Re: newbie question
> To: Mark Knecht <[EMAIL PROTECTED]>
> Cc: ck kernel mailing list <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tuesday 07 Sep 2004 22:14, Mark Knecht wrote:
> > Colin J Thomson wrote:
> > snip.. This could be it?
> > > If you were up for an experiment, you might try:
> > >
> > > 1) Unplug your Ethernet cable and do some experiments. If you are not
> > >receiving packets then the NIC won't generate interrupts (or shouldn't I
> > >think) and you'll have one less bit of confusion.
>
> > I really only use ut2k4 *Online* and spectate to relax?, I will try the
> > game normally (offline), with and without the Ethernet connected.
>
> OK, some success :)
> I just played a few rounds in ut2k4 Offline mode but with the Ethernet still
> connected to my machine, and my audio stutters etc have all but
> disappeared, just the occasional glitch.
>
> So the shared interrupts XT-PIC ohci_hcd, ohci_hcd, eth0, SiS SI7012 is
> the problem I guess..
> So what patch relates to this out of interest and is there something I could
> "tweak"
You could have a look at the interrupt handlers of all the drivers using
that same IRQ: in case of a "foreign" IRQ (one for *another* card),
they need to leave the interrupt handler function immediately,
so they shouldn't be doing any more complex operations before checking
whether the IRQ actually is for their device.
The interrupt function name is the second parameter of a request_irq() call
in a driver...
Which drivers are involved? I could have a look at them, too...
Uhoh, I just found one (linux-2.6.8.1/drivers/usb/core/hcd.c):
irqreturn_t usb_hcd_irq (int irq, void *__hcd, struct pt_regs * r)
{
struct usb_hcd *hcd = __hcd;
int start = hcd->state;
if (unlikely (hcd->state == USB_STATE_HALT)) /* irq sharing? */
return IRQ_NONE;
hcd->saw_irq = 1;
if (hcd->driver->irq (hcd, r) == IRQ_NONE)
return IRQ_NONE;
if (hcd->state != start && hcd->state == USB_STATE_HALT)
usb_hc_died (hcd);
return IRQ_HANDLED;
}
Why the h*ck is that one using unlikely()???
IIRC, this changes cache probability from 95% to 99% or so, which clearly
aggravates the (most likely too common) situation of IRQ sharing
of the USB device with other devices in the system (I've seen IRQ-shared
USB-UHCD many times already!).
You could remove that unlikely() bracing, maybe that helps a bit.
Also, it unnecessarily calculates hdc->state *twice* before and
during the IRQ sharing check, so in total it should use
if (start == USB_STATE_HALT) /* irq sharing? */
return IRQ_NONE;
instead, which now should be quite faster.
Some more explanation:
AFAIK unlikely() should only be used when you're damn sure that this will
NEVER occur (e.g. failure cases), since it will artificially aggravate
penalty of this check in case it does occur.
IRQ sharing is *much* too common to justify using unlikely() here.
*ESPECIALLY* since IRQ sharing is very latency critical!
See
http://groups.google.de/groups?q=likely+unlikely+linux&hl=de&lr=&ie=UTF-8&selm=1mUPO-7Aq-19%40gated-at.bofh.it&rnum=5
http://groups.google.de/groups?selm=linux.kernel.3C450C4A.8A8382A6%40mandrakesoft.com
for better explanations on why using unlikely() here is most "likely" a bad
idea.
Given that even the very often used USB code has two obvious problems
with IRQ sharing optimization, I should probably go through all
IRQ handlers in the kernel and fix similar screwups.
Andreas Mohr
-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
