Transcript Effects of Virtual Cache Aliasing on the Performance of the NetBSD

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, machineindependent 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 higherlevel 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
1600
1400
1200
1000
Aliases
800
(1000's)
600
400
200
0
Total Aliases
Binary
Sh. Libraries
Other
Dev
FS
Net
Workloads
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?