[lkml]   [1998]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: interrupt latency
On Tue, 11 Aug 1998, Chris Wedgwood wrote:

> 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:
> for(i=0;i<iterations;++i){
> make_int_happen_in_5ms();
> start_timing_deltas();
> record_time();
> }
> analyse_median_delta();

That's not how I would do it. I would execute an ioctl to make your
driver do the work. The driver is already installed with its interrupt
attached. The ioctl would return the results....

get and save internal cpu clock tick

get and save internal cpu clock tick (rdsc).
int your interrupt using the INT instruction.
get internal cpu clock tick.
return results

The difference in the cpu clock ticks is the total time
to handle the interrupt.

The difference between the ISR clock tick and the initial
clock tick is the latency time.

Write results to location provided by caller.

Any averaging can be done in user space by repeated ioctl

Note; we use the internal Pentium cycle-counter. If you
don't have a Pentium --sorry.
> 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).

The hardware operates in nanoseconds. It's the software that
presents most of the overhead. Further, you are not going to be
able to change the hardware to improve things. You get what the
vendor provides.

Dick Johnson
Penguin : Linux version 2.1.115 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.

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.031 / U:16.440 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site