Re: interrupt latency

Larry McVoy (lm@bitmover.com)
Tue, 11 Aug 1998 10:14:22 -0600

Oliver Xymoron <oxymoron@waste.org> wrote:
: Something just occurred to me: you can measure latency by making a broken
: interrupt handler. Generate a single interrupt (say clock), handle it,
: acknowledge it incorrectly (so that you've done the same work as you would
: otherwise do to ack it, but you've failed to clear it), then unmask
: interrupts as usual. You will be immediately reinterrupted until you
: properly acknowledge it. On the thousandth iteration, acknowledge it
: correctly. Divide time taken (on the cycle counter, not interrupt-based
: jiffies of course) by 1000 to determine latency (+amortized setup time).
: The handler has to be slightly more complex than the null handler - it has
: to do a countdown and possibly keep the kernel stack from overflowing.

OK, so here's a question: part of interrupt latency should include at
least a couple of register reads across the PCI bus. I'm not much of
a PC driver person, so I'm not sure that what I'm saying make sense,
but every driver I've ever worked on was basically:

take the interrupt
read some state across the bus
do something, usually a DMA
write some state across the bus
clear the interrupt

with the ordering being changed depending on how smart/dumb the driver is.

Anyway, the deal is that reading/writing state across the bus is like
an uncached memory access and used to take around a usec or so. If,
and this shows how little I know, the read/write is 10% or so of a null
interrupt, then I'd like to include that cost. Any ideas?

Also, is anyone out there interested in making this benchmark exist? I
really want to know what these numbers are...

-
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.altern.org/andrebalsa/doc/lkml-faq.html