[lkml]   [1999]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: linux interrupt handling problem

    On Thu, 11 Nov 1999, Stephen C. Tweedie wrote:

    > There was a Usenix paper a couple of years ago:

    Which you can't access without USENIX membership. :(

    > at which they did an evaluation of the normal splx() mechanism in NetBSD
    > with a simplified, Linux-like mechanism. The simpler one won
    > hands-down. They did note that spl made sense on older machines where
    > interrupt routines were, relatively, much longer due to the slower clock
    > speeds, but concluded that it didn't make sense on modern, fast CPUs.

    I think of something completly different. Basically I created an extended
    set of atomic macros as in asm/atomic.h. But I added an explicit lock for
    them. This way I can use them more generic and they are not limited to
    counter purposes, but they are also useable for full 32/64 bit values
    (e.g. pointers). On machines there appropriate instructions are available
    they can be used, otherwise we have to fallback to a normal spinlock.

    > Their proposal in the end is to protect kernel critical sections with
    > cli/sti, but to keep interrupts enabled during IRQs and rely on the PIC
    > to keep the interrupt line disabled during the ISR. Odd, that looks
    > familiar, doesn't it? :-)

    So they assumed a pc architecture, but that's not my real problem. My
    problem is that interrupt handler are allowed to assume a specific
    interrupt architecture.
    BTW our interrupt handlers could be much shorter, we're doing to much at
    the interrupt level, especially most of the block devices. They don't look
    for the next request until the next interrupt. I think of an extra device
    queue which contains a preprocessed buffer request, so that at interrupt
    level not much more is done than reinitializing the hardware for the next
    request. This would greatly improve interrupt perfomance, but it would
    also seperate interrupt synchronisation from the buffer mechanism. For a
    few requests I expect only slightly more overhead, but much better
    perfomance under load.

    bye, Roman

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

     \ /
      Last update: 2005-03-22 13:54    [W:0.023 / U:51.584 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site