> 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.
Some can be quite a bit simpler, especially interrupts that simply signal
completion. They can do all their work in bottom halves.
> 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?
Hmmm.. that's a different number than what I usually hear talked about
when I hear about interrupt latency benchmarking, which is generally much
how long it takes the kernel to get from interrupt asserted to interrupts
unmasked for a null handler. This includes all the regular bookkeeping
like updating interrupt counts, complexity like enabling nested
interrupts, and, if you have a drivers that don't live in ring 0, the ring
transition time.
Throw in the fact that PCs can have two or three different buses with very
different speeds, and it begins to look like bus speed is something that
should be measured independently.
> Also, is anyone out there interested in making this benchmark exist? I
> really want to know what these numbers are...
Even if it's not portable to other OSes, writing a fairly generic Linux
benchmark is probably possible and gets you to a fair number of
architectures.
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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