Effects of Virtual Cache Aliasing on the Performance of the NetBSD Operating System

1. Effects of Virtual Cache Aliasing on the Performance of the NetBSD Operating System Rafal Boni CS 535 Project Presentation

2. 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.

3. 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?

4. 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.

5. 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.

6. 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].

7. 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!

8. 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.

9. 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!

10. Baseline results

11. 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!

12. Questions?