Re: user-mode interrupt handling

From: Michael Raymond <>
Date: 2005-03-03 09:03:20
    I've done some better quality benchmarking to compare the two approaches
and here are my results.  This was done on an idle 1Ghz system with kernel

      Total Cost of Empty Handler    Time to First User Instruction
ULI   2.9us                          1.34us
UMIH  3.4us                          7.98us

    Total Cost was measured as the slow down per interrupt of an application
doing other work and periodically being interrupted.  First Instruction was
measured as the time from the IRQ code to the first user space instruction.

    For my purposes, Mr Amdahl says that the Total Cost difference is
irrelevant.  In the application space that I'm targetting, I can expect code
running at 50+ kHz and needing to respond to every interrupt before the next
one.  For those kind of applications, the latency issue becomes a problem.
    Prof Chubb, our code bases share a good deal of common infrastructure
and I imagine at a user API level we could produce library code that allows
the user to not care about the underlying methods.  ULI users need really
low latency while UMIH appears to target environments that can batch work.
    With the goal of getting something checked in, would it make sense to
merge our code that affects common Linux C code?

On Thu, Feb 24, 2005 at 08:44:01AM +1100, Peter Chubb wrote:
> For your delectation --- here's the stuff to be able to handle
> interrupts from user space, for all architectures that use
> GENERIC_HARDIRQS (which of course includes IA64).
> I'm not expecting this to be included; it's just for comparison with the
> ULI patch that Michael Raymond posted a pointer to.

Michael A. Raymond              Office: (651) 683-3434
Core OS Group                   Real-Time System Software
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Wed Mar 2 17:05:20 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:36 EST