In all three architectural models a saving of at least
is possible.
Context switch and trap times on a RISC CPU such as the Intel i860
used in the Intel Paragon, can be considerable. Saving and restoring
the floating-point pipeline state is especially costly, bringing the
total cost to several tens of micro seconds.
We anticipate that most handlers are short and will execute quickly.
In these cases, some overhead to safely execute a handler in the
kernel can be easily tolerated. However, if the overhead of
executing a handler in the kernel becomes larger than
, it would be better to run the handler at user
level.
Figure 2.8 illustrates the relationship between a handler in
the kernel and one at the user level. The handler at the user level
pays an up-front cost of at least 
before it
starts executing. ( varies with the handler and the
method used to execute a handler in the kernel.
is constant for a given operating system.) A handler running in
supervisor mode has to be prevented from gaining privileges that it
would not have if it ran in user mode. The methods used to prevent
handlers from gaining privileges, impose an overhead and make the
kernel handler execute more slowly. The differences in execution
speeds are represented by the different slopes of the two curves.
There is a crossover point after which the overhead of executing the
handler in the kernel exceeds the time taken by the user level
handler. Therefore, if the amount of work a handler has to do
exceeds a certain threshold, then it is better to run the handler in
user mode.
Figure 2.8: User Level and Kernel Level Handlers:
A handler in the kernel runs slower because of the
overhead to ensure integrity of the system. A user-level
handler pays a cost up front () but
then executes faster because no memory access checks
are needed for example. The overhead to run in the kernel
accumulates until it becomes larger than .
At that point a handler should be run at user level.
is determined by the hardware and the operating
system. The overhead of running a handler in the kernel is
determined by the method used to ensure the integrity of the
system. In the next section we will look at various methods to run
handlers in the kernel. We find that each method has its own
overhead, dependent on the amount of work (number of instructions)
and the type of work (load and store versus computation) a handler
performs.
In Figure 2.9 we give a hypothetical example of how the various methods of running a handler in the kernel compare to running the handler at user level. Since the overhead characteristics for each method are dependent on the instruction mix of the handler, an analysis would have to be done for each handler of interest. The varying slopes of each step of each curve represent memory accesses and CPU internal instructions. The cost for the two types of operations are different in each method. Memory access patterns are also different, giving each method a unique execution profile for a given handler. Since the amount of work a given handler performs is bounded, it will be possible to determine the method that executes a given handler the fastest.
Figure 2.9: Example of Kernel Handlers:
Depending on the method chosen and the particular handler,
the time it takes to do a given amount of work will change.
Choose the method that requires the least time for a given
handler. is the cost to get a handler
started in user space.
The class of handlers described in the examples of Section 1 share two common characteristics: they are short and use simple operations. It is possible that for this class of handlers one of the methods described in the next section executes fastest most of the time. We will perform measurements under the Puma operating system running on an Intel Paragon and the DOE Teraflop system to characterize the execution profile of this class of handlers and find the method that is best suited for these handlers.