Re: Interrupt API change

From: Scott Long (scottl_at_freebsd.org)
Date: 01/11/04

  • Next message: Jeff Roberson: "Re: Interrupt API change" 
    Date: Sat, 10 Jan 2004 21:13:08 -0700
To: Bruce Evans <bde@zeta.org.au>

    Bruce Evans wrote:
    >
    > That'a about all it can do. In the shared irq case, there is no
    > alternative to calling all the handlers if one of the handlers did
    > something, since activity by one handler is unrelated to activity by
    > others (except as an optimization that only works in the edge triggered
    > case -- devices usually rarely interrupt concurrently so assuming that
    > thety never do is usually most efficient). In the non-shared case,
    > individual handlers can better decide about interrupt storms in a
    > device-specific way. The non-shared case will hopefully be almost all
    > cases when APIC support becomes standard on i386's.
    >

    This is way too overly optimistic. Interrupt routing is still limited
    by things like the number of physical PCI INTx lines. The APIC can't
    do anything about devices that share the same physical line.

    MSI will help this, but I suspect that MSI will only be supported on
    the higher-end PCI/PCI-X cards, at least until PCI-Express is adopted.
    I wouldn't expect the shared PCI INTx line problem to go away for
    at least another 5-7 years.

    There is no reason to duplicate interrupt storm heuristics in every
    single PCI driver. For now, the change will be essentially a no-op.
    However, getting it in will allow us to experiment with it in the
    future with ease. I'm not advocating that we break shared interrupt
    semantics and use this to short-circuit handlers.

    >
    > The first level interrupt handler should call (or schedule) other levels
    > as necessary (as in RELENG_4, but not using inefficient scheduling as in
    > -current).

    I understand, and that's why I haven't committed to doing it yet.

    >
    > Bruce
    >

    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Jeff Roberson: "Re: Interrupt API change"

    Relevant Pages

    • Re: [PATCH 2/2] Debug handling of early spurious interrupts
      ... handlers tend to dwell in crufty old drivers which not many people use. ... I managed to find some somewhat buggy interrupt handlers. ... incorrect or dubious driver behaviour, and there is value in weeding these ...
      (Linux-Kernel)
    • RE: Problem with twa in HEAD
      ... >> But, the interrupt handler in twa is still active at this time, ... > the driver poll vector, and that by calling it enough times the driver ... > twa driver isn't completing the outstanding I/O. ... > state to the handlers. ...
      (freebsd-current)
    • Re: Interrupt API change
      ... >> alternative to calling all the handlers if one of the handlers did ... Interrupt routing is still limited ... > by things like the number of physical PCI INTx lines. ... > MSI will help this, but I suspect that MSI will only be supported on ...
      (freebsd-arch)
    • Re: [PATCH 2/2] Debug handling of early spurious interrupts
      ... Thus drivers ought to be able to handle ... But nobody ever said that non-shared interrupt handlers need to be able to ... CPU: IntelXeonCPU 3.20GHz ...
      (Linux-Kernel)
    • Re: [PATCH 6/24] make atomic_read() behave consistently on frv
      ... cpu_relaxcontains a barrier, so it should do the right thing. ... What problems with interrupt handlers? ... it can affect interactions with interrupt handlers. ...
      (Linux-Kernel)