[lkml]   [1998]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: interrupt latency
On Mon, Aug 10, 1998 at 10:10:56PM -0400, Richard B. Johnson wrote:
> On Mon, 10 Aug 1998, Larry McVoy wrote:

> > I reall wish this wasn't the case because I would dearly love to
> > be able to have interrupt latency as a benchmark test in lmbench.
> > Are you sure there is no way to do this in software? What if you
> > had some way to generate interrupts essentially continuously?
> With the Intel machines, you can.

No really suitable for lmbench I would think...

> You can generate a software interrupt. You have to make, perhaps, a
> dummy driver that operates in ring 0 (kernel mode).

But won't this interrupt occur immediately... is there anyway to do
something like:



i.e. delay the onset of the interrupt until you are already timing it
and everything is hot in cache, that way you get raw interrupt time
only, and hopefully the spread of times will be tightly concentrated
except for when the time/slice or some other kind of interrupt
occurs, which should be pretty easy to weed out over 10,000
iterations or so.

? <- hmm... where to place the question mark. hmm...

> This device could acquire an interrupt (IRQ) from the kernel. It
> could also generate a software interrupt for the IRQ number (they
> are not the same).

OK, so if I have a dummy device that has done a request_irq using an
empty function for interrupt (say) 3, then how to I in software
trigger this interrupt? (I'm more or less ia32 illiterate and have,
but this sound like it could be useful debugging drivers).

> This time would include all the software overhead, but not the
> hardware overhead (which should be very, very much smaller than the
> software overhead). The fact that the kernel will mask/ACK/unmask
> the hardware controller(s) will not hurt the execution of the
> software interrupt.

The hw overhead is going to be different depending on what kind of
interrupt it is anyhow, and what bus it originated, whether its
XT-PIC or APIC, what day of the week it is, etc. - but I would think
the software times are going to be more interesting here, especailly
as different OS have different entry and exit mechanisms, and some
might be slower than others. (For example, its been verified on a
Pentium 90, it can take over 10,000 cycles for NT to service certain
interrupts, whereas Windows95 it takes less that 3,000 cycles for the
same interrupt).

> Now, that said, since all interrupts are handled the same except
> for the very small interval for the cascade, you could just review
> the generated assembly and calculate the execution times which
> might be simpler than writing the dummy driver.

Why not mask out the interrupt and time the code execution?


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:43    [W:0.062 / U:1.264 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site