Check out the new USENIX Web site. next up previous
Next: Experimental Setup & Workload Up: Design & Implementation Previous: In-Kernel Implementation

Overhead


For DeBox to be attractive, it should generate low kernel overhead, especially in the common case. To quantify this overhead, we compare an unmodified kernel, a kernel with DeBox support, and the modified kernel with DeBox activated. We show these measurements in Table 2. The first column indicates the various system calls - getpid(), gettimeofday(), and pread() with various sizes. The second column indicates the time required for these calls on an unmodified system. The remaining columns indicate the additional overhead for various DeBox features.


Table: DeBox microbenchmark overheads - Base time uses an unmodified system. All times are in microseconds
    DeBox without DeBox
call name base call trace call trace
or read size time off on off on
getpid 0.46 +0.00 +0.50 +0.03 +1.45
gettimeofday 5.07 +0.00 +0.43 +0.03 +1.52
pread 128B 3.27 +0.02 +0.56 +0.21 +2.03
256 bytes 3.83 +0.00 +0.59 +0.26 +2.02
512 bytes 4.70 +0.00 +0.69 +0.28 +2.02
1024 bytes 6.74 +0.00 +0.68 +0.27 +2.02
2048 bytes 10.58 +0.03 +0.68 +0.26 +2.01
4096 bytes 18.43 +0.03 +0.74 +0.29 +2.16



We separate the measurement for call history tracing since we do not expect it will be activated continuously. These numbers show that the cost to support most DeBox features is minimal, and the cost of using the measurement infrastructure is tolerable. Since these costs are borne only by the applications that choose to enable DeBox, the overhead to the whole system is even lower. The performance impact with DeBox disabled, indicated by the 3rd column, is virtually unnoticeable. The cost of supporting call tracing, shown in the 5th column, where every function entry and exit point is affected, is higher, averaging approximately 5% of the system call time. This overhead is higher than ideal, and may not be desirable to have continuously enabled. However, our implementation is admittedly crude, and better compiler support could integrate it with the function prologue and epilogue code. We expect that we can reduce this overhead, along with the overhead of using the call tracing, with optimization.


Table: DeBox macrobenchmark overheads
  tar-gz a directory with make
  1MB file 10MB file kernel
base time 275.61 ms 3078.50 ms 236.96 s
basic on +0.97 ms +22.73 ms +1.74 s
full support +1.03 ms +44.58 ms +7.49 s



Since microbenchmarks do not indicate what kinds of slowdowns may be typically observed, we provide some macrobenchmark results to give some insight into these costs in Table 3. The three systems tested are: an unmodified system, one with only ``basic'' DeBox without call trace support, and one with complete DeBox support. The first two columns are times for archiving and compressing files of different sizes. The last column is for building the kernel. The overheads of DeBox support range from less than 1% to roughly 3% in the kernel build. We expect that many environments will tolerate this overhead in exchange for the flexibility provided by DeBox.




next up previous
Next: Experimental Setup & Workload Up: Design & Implementation Previous: In-Kernel Implementation
Yaoping Ruan
2004-05-04