| To: | jamal <hadi@xxxxxxxxxx> |
|---|---|
| Subject: | Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5 |
| From: | Ingo Molnar <mingo@xxxxxxx> |
| Date: | Wed, 3 Oct 2001 19:28:07 +0200 (CEST) |
| Cc: | <linux-kernel@xxxxxxxxxxxxxxx>, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, Benjamin LaHaise <bcrl@xxxxxxxxxx>, <netdev@xxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Simon Kirby <sim@xxxxxxxxxxxxx> |
| In-reply-to: | <Pine.GSO.4.30.0110031109430.4833-100000@xxxxxxxxxxxxxxxx> |
| Reply-to: | <mingo@xxxxxxx> |
| Sender: | owner-netdev@xxxxxxxxxxx |
On Wed, 3 Oct 2001, jamal wrote:
> use the netif_rx() return code and hardware flowcontrol to fix it.
i'm using hardware flowcontrol in the patch, but at a different, higher
level. This part of the do_IRQ() code disables the offending IRQ source:
[...]
desc->status |= IRQ_MITIGATED|IRQ_PENDING;
__disable_irq(desc, irq);
which in turn stops that device as well sooner or later. Optionally, in
the future, this can be made more finegrained for chipsets that support
device-independent IRQ mitigation features, like the USB 2.0 EHCI feature
mentioned by David Brownell.
i'd prefer it if all subsystems and drivers in the kernel behaved properly
and limited their IRQ load - but this does not always happen and users are
hit by irq overload situations.
Your NAPI patch, or any driver/subsystem that does flowcontrol accurately
should never be affected by it in any way. No overhead, no performance
hit.
Ingo
|
| Previous by Date: | Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5, Ben Greear |
|---|---|
| Next by Date: | Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5, Benjamin LaHaise |
| Previous by Thread: | Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5, jamal |
| Next by Thread: | Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5, jamal |
| Indexes: | [Date] [Thread] [Top] [All Lists] |