lots of them, though they might call it different things. sometimes
the hardware may "support" a "feature" but we don't enable it because
it hurts more than it helps.
by way of example, fxp, em, bge, and sis (to name a few) support such
a thing. grepping for
strings like {delay, hold, coales, interrupt, throttl, mitigat} in the
let's say your NIC fires an interrupt every time you get/send a packet
- the OS has to stop whatever it was doing, figure out who sent the
interrupt, decide what to do about it, and then go do it. Kind of like
a telephone call.
At low packet rates this is not a problem ... millions of processor
cycles between interrupts means plenty of time to get work done. Now
we crank that up a few orders of magnitude... suddenly your CPU is so
busy responding to these interrupts that it never has time to get any
real work done. Kind of like a telephone "ringing off the hook"
Enter interrupt mitigation. In general this allows the card to delay
the interrupt for a short while, just in case more packets arrive
right away. An interrupt happens, but this time there are ... say,
8... packets to handle. The overhead of handling the interrupt has
been effectively reduced to 1/8, at the cost of introducing a small
amount of delay. Kind of like sending your calls to voicemail and
returning calls in a batch once an hour.
Too little delay, and your kernel can get run into the ground by
interrupts. Too much delay and your network sucks because everybody is
waiting for your network card to tell the kernel "hey, i have packets
for you", or you run out of buffers on the card and start dropping
packets.
tuning interrupt mitigation is a bit tricky. one example of interrupt
migitation gone badly might be Vista's apparent inability to
simultaneously play sound and do high speed net I/O. the idea was ok -
prevent net I/O from totally killing more time-sensitive processes.
the execution was flawed...
--
GDB has a 'break' feature; why doesn't it have 'fix' too?
