On Tue, 2 Oct 2001, Ingo Molnar wrote:
>
> - the irq handling code has been extended to support 'soft mitigation',
> ie. to mitigate the rate of hardware interrupts, without support from
> the actual hardware. There is a reasonable default, but the value can
> also be decreased/increased on a per-irq basis via /proc/irq/NR/max_rate.
Adn how do you select max_rate sanely? It depends on how heavy each
interrupt is, the speed of the CPU etc etc. A rate that works for a
network card with a certain packet size may be completely ineffective on
the same machine with the same network card but a different packet size.
When you select the wrong number, you slow the system down for no good
reason (too low a number) or your mitigation has zero effect because the
system can't do that many interrupts per tick anyway (too high a number).
Saying "hey, that's the users problem", is _not_ a solution. It needs to
have some automatic cut-off that finds the right sustainable rate
automatically, instead of hardcoding random default values and asking the
user to know the unknowable.
Automatically doing the right thing may be hard, but it should be
solvable. In particular, something like the following _may_ be a workable
approach, rather than having a hardcoded limit:
- have a notion of "made progress". Certain events count as progress, and
will reset the interrupt count.
Examples of "progress":
- idle task loop
- a context switch
- depend on the fact that on a PC, the timer interrupt has the highest
priority, and make the timer interrupt do something like
if (!made_progress) {
disable_next_irq = 1;
} else
made_progress = 0;
- have all other interrupts do something like
if (disable_next_irq)
goto mitigate;
which just says that we mitigate an irq _only_ if we didn't make any
progress at all. Rather than mitigating on some random count that can
never be perfect.
(Tweak to suit your own definition of "made progress" - maybe you'd like
to require more than just a context switch).
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:17 EST