lkml.org 
[lkml]   [2001]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5

Andreas Dilger writes:

> If you get to the stage where you are turning off IRQs and going to a
> polling mode, then don't turn IRQs back on until you have a poll (or
> two or whatever) that there is no work to be done. This will at worst
> give you 50% polling success, but in practise you wouldn't start polling
> until there is lots of work to be done, so the real success rate will
> be much higher.
>
> At this point (no work to be done when polling) there are clearly no
> interrupts would be generated (because no packets have arrived), so it
> should be reasonable to turn interrupts back on and stop polling (assuming
> non-broken hardware). You now go back to interrupt-driven work until
> the rate increases again. This means you limit IRQ rates when needed,
> but only do one or two excess polls before going back to IRQ-driven work.

Hello!

Yes this has been considered and actually I think Jamal did this in one of
the pre NAPI patch. I tried something similar... but instead of using a number
of excess polls I was doing excess polls for a short time (a jiffie). This
was the showstopper mentioned the previous mails. :-)

Anyway it up to driver to decide this policy. If the driver returns
"not_done" it is simply polled again. So low-rate network drivers can have
a different policy compared to an OC-48 driver. Even continues polling is
therefore possible and even showstoppers. :-) There are protection for
polling livelocks.

Cheers.
--ro
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:04    [W:0.650 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site