lkml.org 
[lkml]   [1998]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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....

    isr()
    {
    get and save internal cpu clock tick
    return
    }

    driver()
    {
    get and save internal cpu clock tick (rdsc).
    int your interrupt using the INT instruction.
    get internal cpu clock tick.
    calculate
    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
    calls.

    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.

    Cheers,
    Dick Johnson
    ***** FILE SYSTEM WAS MODIFIED *****
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.023 / U:62.780 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site