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 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();

    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?




    -cw

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