On Thu, 11 Nov 1999, Stephen C. Tweedie wrote:
> There was a Usenix paper a couple of years ago:
>
> http://www.usenix.org/publications/library/proceedings/ana97/small.html
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/