Performance Analysis and Optimization of the Hurricane File System ...

CHAPTER 7. MACROBENCHMARK 77
7.4.1 Results
With the user-level configuration, the amount of stress placed on the file system was significantly reduced,
migrating it to the VFS and FCM components of the operating system instead. As shown in Figure 7.11 8 ,
user-level scalability was largely unaffected by the optimizations. The user-level unoptimized and optimized
versions performed similarly. Further investigation revealed that, in the unoptimized user-level version on
8 processors, only about 9% of a thread’s execution time was spent in the file system. At best, we could
reduce file system overhead down to 0% and improve user-level performance by at most 9% 9 . In fact, in the
fully optimized user-level version (optimized 2), only 2% of a thread’s execution time was spent in the file
system. Based on cycle counts, these improvements reduced file system usage time by 90% (on an 8 processor
system). From this perspective, the optimizations were effective, however, in the larger context of overall
execution time, the optimizations had little impact.
When the Web application was run at user-level, scalability problems were not caused by the the file
system, but rather were caused by other components of the operating system, such as the FCM and the
VFS. Optimizing these components were beyond the scope of this thesis.
Since only 9% of a thread’s execution time was spent in the file system, a larger Web log trace could have
enabled the Web server simulator to add the necessary stress to the file system, causing this portion of time
to increase significantly. A larger workload would cause more data to be cached and accumulated in the
FCM until physical memory was depleted to the point where cache pages must be evicted. The subsequent
reloading of previously evicted file data in the FCM would invoke the file system and increase its load. It
could transform the FCM/VFS-bound workload into a HFS-bound workload. However, this configuration
was not possible because of time constraints, speed limitations of the SimOS simulator, and the lack of
page eviction support in the version of K42 used. Regardless, it is important to ensure that the file system
component is scalable when highly stressed, as the server-level experiments have demonstrated.
Since the measurements were taken during the second run of the experiment, we were curious as to the
results from the first run. There should be more stress on the file system since the FCM and VFS caches
are initially empty and must be filled by acquiring information from the file system. The results, shown in
Figure 7.12, indicate that the unoptimized version experienced scalability problems while the optimized
version scaled much better. Upon further examination, we found at least 74% of a thread’s execution time
was spent in the file system on an unoptimized 8 processor configuration. Such a large proportion meant
that the file system was adequately stressed. Using the fully optimized configuration reduced this portion
down to less than 25%. These results indicate that, under appropriate conditions, the optimizations were
effective on the user-level Web server simulator.
8 User-level results on 12 processors could not be obtained due to OS stability problems.
9 In fact, over-all user-level performance improved by 23%. The additional improvement was most likely due to over-all
reduced memory-bus contention.