Presentation on theme: "Effects of Virtual Cache Aliasing on the Performance of the NetBSD Operating System Rafal Boni CS 535 Project Presentation."— Presentation transcript:
Effects of Virtual Cache Aliasing on the Performance of the NetBSD Operating System Rafal Boni CS 535 Project Presentation
Background and motivation Why NetBSD? Runs on > 10 CPU families, > 45 different platforms all from one code base. Has made it a point to provide clean, machine- independent interfaces to major kernel systems Why cache performance? To find out more about the VM system As a practical matter of supporting a new machine with a virtually addressed cache.
CPU Cache Architectures Small, fast store between CPU registers and slower but larger main memory. Many design choices: Lookup: virtual or physical addresses? Tagging: virtual or physical addresses? Associativity: is each “index” able to store more than one cached item (“line”)? Write policy: write-back or write-through?
Physical (“Real”) Caches Using physical addresses for both lookup and tagging, cache can effectively become invisible to OS This is a serious plus for the OS developer! However, address translation must be performed before cache lookup can happen: This is a serious performance issue for on-die cache! Probably acceptable for secondary and higher- level caches, though.
Virtual Caches Why? The need for speed! Uses un-translated virtual address for lookup No bottleneck, can do address translation in parallel with cache lookup! Allows fast, on-die cache design. The downsides? Requires OS to manage cache explicitly Possible issue of cache aliasing, requires much more sophisticated software management.
Cache aliases: what are they? Multiple mappings of one physical page at different addresses in virtual space. Writes via one mapping may not be visible to others! As in the example from [Chao90].
How to deal with aliases? Have your hardware detect them, OS fix them up. But this costs silicon! Prohibit multiple mappings to a single physical page – global address space. Keep only a single page of any set of aliased pages mapped at a time. Force all read/write shared pages to be accessed un-cached. Best of all – try to avoid creating aliases!
Let’s get to the meat of it! My goals are: To evaluate how well NetBSD deals with cache aliases – how often it generates them, how it deals with them, etc. To propose some enhancements to the current state of the art… And to benchmark those enhancements. Many of the proposed enhancements come from OS research literature.
The measure of success To measure the effects of the proposed enhancements, I use three application-level workloads: “Development workload” – compiling the “tcsh” UNIX shell “File System workload” – creation and deletion of a number of files; reused the “tcsh” source distribution. “Networking workload” – by design distinct from above, only takes into account data transfer, not FS operations!
Proposed enhancements Have VM system use virtual addresses to initialize pages Currently do so using physical address, which causes cache thrash and requires extra cache flushes to prevent aliases. So far, this hasn’t show any performance benefit – still debugging implementation. Better page placement by OS key to performance!