[lkml]   [2001]   [Oct]   [1]   [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, Oct 01, 2001 at 08:41:20PM -0400, jamal wrote:
    > >The new mechanizm:
    > >
    > >- 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.
    > I am sorry, but this is bogus. There is no _reasonable value_. Reasonable
    > value is dependent on system load and has never been and never
    > will be measured by interupt rates. Even in non-work conserving schemes

    It is not dependant on system load, but rather on the performance of the
    CPU and the number of interrupt sources in the system.

    > There is already a feedback system that is built into 2.4 that
    > measures system load by the rate at which the system processes the backlog
    > queue. Look at netif_rx return values. The only driver that utilizes this
    > is currently the tulip. Look at the tulip code.
    > This in conjuction with h/ware flow control should give you sustainable
    > system.

    Not quite. You're still ignoring the effect of interrupts on the users'
    ability to execute instructions during their timeslice.

    > [Granted that mitigation is a hardware specific solution; the scheme we
    > presented at the kernel summit is the next level to this and will be
    > non-dependednt on h/ware.]
    > >(note that in case of shared interrupts, another 'innocent' device might
    > >stay disabled for some short amount of time as well - but this is not an
    > >issue because this mitigation does not make that device inoperable, it
    > >just delays its interrupt by up to 10 msecs. Plus, modern systems have
    > >properly distributed interrupts.)
    > This is a _really bad_ idea. not just because you are punishing other
    > devices.

    I'm afraid I have to disagree with you on this statement. What I will
    agree with is that 10msec is too much.

    > Lets take network devices as examples: we dont want to disable interupts;
    > we want to disable offending actions within the device. For example, it is
    > ok to disable/mitigate receive interupts because they are overloading the
    > system but not transmit completion because that will add to the overall
    > latency.

    Wrong. Let me introduce you to my 486DX/33. It has PCI. I'm putting my
    gige card into the poor beast. transmitting full out, it can receive a
    sufficiently high number of tx done interrupts that it has no CPU cycles left
    to run, say, gated in userspace.

    Falling back to polled operation is a well known technique in realtime and
    reliable systems. By limiting the interrupt rate to a known safe limit,
    the system will remain responsive to non-interrupt tasks even under heavy
    interrupt loads. This is the point at which a thruput graph on a slow
    machine shows a complete breakdown in performance, which is always possible
    on a slow enough CPU with a high performance device that takes input from
    a remotely controlled user. This is *required*, and is not optional, and
    there is no way that a system can avoid it without making every interrupt
    a task, but that's a mess nobody wants to see in Linux.


    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.025 / U:19.260 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site