Baseline Performance

Figure 9:VS effect on HTTP throughput

Figure 10:Performance of intercepted and new system calls

Basic performance measurements show that the dynamic VS classification layer degrades overall system performance only minimally. If we intercept a complex system call like fork, the overhead of classifying the new process is small -- only 1.3% -- (see Figure 10(b), classify). Nevertheless, the raw performance of intercepted system calls can decrease significantly if the intercepted call is very simple like open. We observed 30% cost increase for the open/close pair if the VS affiliation changed with every execution of the loop (reclassify) in Figure 10(a). Just finding a classification rule (match) or not finding one (mismatch) is much cheaper. The high relative overhead for simple calls results from the almost constant classification overhead. An important point shown in Figure 10(a) is that binding processes to VSs from user-space (explicit classification) performs much worse than kernel-based classification because of the system call overhead. Explicit classification requires the executing process to classify itself and the resources that it uses and creates by calling the servctl system call. In our measurements we compared the performance of a sample program using (implicit) classification rules against a modified version of the program that explicitly updated affected VS bindings. The performance numbers strongly support the use of kernel-based (implicit) classification. For the sake of completeness, Figure 10(c) summarizes the cost of querying VS attributes and administering the VS hierarchy.

To estimate the overall performance impact of the kernel modifications including scheduler changes, resource limit enforcement, and the cost of system call interception, we measured how the performance of the Apache HTTP server [14] is affected by the OS changes. Figure 9 shows that the VS abstraction affects the system's HTTP performance only up to 2.5%, depending on the number of simultaneous client connections. The bi-modal shape of the performance loss graph in Figure 9 can be explained as follows. Apache keeps some spare processes alive to serve incoming connections faster. Once the number of simultaneous connections offered to Apache increases to an extent that there are not always enough of these spares, Apache begins to fork more connection-handling processes on-demand, which explains the increase in overhead up to 80 simultaneous connections. Beyond this point, the file system cache hit ratio goes down so that the low performance of the file system begins to dominate overall system performance, thus decreasing the relative impact of our OS changes.