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!

Baseline results

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!

Questions?