In article <Pine.LNX.4.33.0110031920410.9973-100000@localhost.localdomain>,
Ingo Molnar <mingo@elte.hu> wrote:
>
>well, just tested my RAID testsystem as well. I have not tested heavy
>IO-related IRQ load with the patch before (so it was not tuned for that
>test in any way), but did so now: an IO test running on 12 disks, (5 IO
>interfaces: 3 SCSI cards and 2 IDE interfaces) producing 150 MB/sec block
>IO load and a fair number of SCSI and IDE interrupts, did not trigger the
>overload code.
Now test it again with the disk interrupt being shared with the network
card.
Doesn't happen? It sure does. It happens more often especially on
slightly lower-end machines (on laptops it's downright disgusting how
often _every_ single PCI device ends up sharing the same interrupt).
And as the lower-end machines are the ones that probably can be forced
to trigger the whole thing more often, this is a real issue.
And on my "high-end" machine, I actually have USB and ethernet on the
same interrupt. It would be kind of nasty if heavy network traffic
makes my camera stop working...
The fact is, there is never any good reason for limiting "trusted"
interrupts, ie anything that is internal to the box. Things like disks,
graphics controllers etc.
Which is why I like the NAPI approach. If somebody overloads my network
card, my USB camera doesn't stop working.
I don't disagree with your patch as a last resort when all else fails,
but I _do_ disagree with it as a network load limiter.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:29 EST