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

    On Mon, 1 Oct 2001, Ben Greear wrote:

    > So, when you turn off the IRQs, are the drivers somehow made aware of
    > this so that they can go into polling mode? That might fix the 10ms
    > latency/starvation problem that bothers me...

    the latest, -D9 patch does this. If drivers provide a (backwards
    compatible) ->poll_controller() call then they can be polled by kpolld.
    There are also a few points within the networking code that trigger a poll
    pass, to make sure events are processed even if networking-intensive
    applications take away all CPU time from kpolld. The device is only polled
    if the IRQ is detected to be in overload mode. IRQ-overload protection
    does not depend on the existence of the availability of the
    ->poll_controller(). The poll_controller() call is very simple for most
    drivers. (It has to be per-driver, because not all drivers advance their
    state purely via their device interrupts.)

    but kpolld itself and auto-mitigation is not limited to networking - any
    other driver framework that has high-irq-load problems can use it.

    > I'm more worried about dropped pkts. If you can receive 10k packets
    > per second, then you can receive (lose) 100 packets in 10ms....

    yep - this does not happen anymore, at least under the loads i tested
    which otherwise choke a purely irq-driven machine. (It will happen in a
    gradual way if load is increased further, but that is natural.)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:03    [W:0.021 / U:3.120 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site