Memory Hierarchy
Memory hierarchy arranges registers, caches, main memory, and storage in layers with different speed, capacity, and cost. It keeps frequently used data near the processor while larger, slower layers retain the rest.
itComputer architecture and hardware | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Intro
Memory Hierarchy
A memory hierarchy is the layered path between a processor and the data or instructions it needs. The upper layers are small and fast. Lower layers hold more data but take longer to reach. A typical path begins with registers, continues through one or more processor caches, reaches dynamic random-access memory, and may extend through virtual memory to persistent storage.
No single storage technology provides the lowest latency, largest capacity, lowest cost, and persistence at the same time. A hierarchy combines technologies with different strengths. It works because programs usually reuse a limited working set during a given interval.
The access path
A load or instruction fetch starts with an address. The processor first checks the closest applicable storage. A register operand is already available to an execution unit. Other addresses normally pass through an L1 cache, then larger downstream caches, and finally main memory. If virtual memory must bring an absent page from storage, the operating system joins the path.
Each cache holds copies of blocks from the next level. A cache hit finds the requested block at the checked level. A cache miss sends the request farther down the hierarchy. The returned block fills a cache line so later accesses can hit closer to the processor.
Two forms of locality make those copies useful:
- Temporal locality means a recently accessed location is likely to be accessed again soon.
- Spatial locality means an access makes nearby locations more likely to be accessed soon.
A loop that repeatedly reads a small array has temporal locality. Sequentially scanning the array has spatial locality. A pointer-chasing workload spread across memory may exhibit little spatial locality because adjacent bytes are not the next useful data.
Layers and managers
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://ocw.mit.edu/courses/6-004-computation-structures-spring-2017/pages/c14/c14s1/
Supports
- Layered use of registers, multilevel SRAM caches, DRAM, and nonvolatile storage
- Locality, cache hits, cache misses, fills, line organization, and management boundaries
- Cache address decomposition, associativity, replacement, and write-policy concepts
- https://ocw.mit.edu/courses/6-004-computation-structures-spring-2017/pages/c16/c16s1/
Supports
- Main memory and secondary storage as hierarchy levels
- Virtual addresses, physical addresses, MMU translation, pages, and software-managed misses
- Large blocks, high associativity, and write-back behavior in virtual memory
- https://notes.cs61c.org/content/caches-intro/memory-hierarchy/
Supports
- Memory hierarchy order and the latency, capacity, and cost tradeoff
- Copies across hierarchy levels and hardware or software management roles
- Multilevel cache request flow
- https://notes.cs61c.org/content/caches-intro/amat/
Supports
- Definitions of hit time, miss rate, and miss penalty
- Single-level and recursive multilevel AMAT formulas
- Local lower-level miss rate interpretation
- https://notes.cs61c.org/content/caches-ii/set-associative/
Supports
- Direct-mapped, set-associative, and fully associative placement choices
- Address tag, index, offset, replacement scope, and conflict tradeoffs
- Replacement policies and compatibility with write policies
- https://notes.cs61c.org/content/caches-ii/fully-associative/
Supports
- Write-through and write-back behavior
- Dirty bits and eviction of modified lines
- Cache metadata and line-size tradeoffs
- https://notes.cs61c.org/content/parallel-tlp/cache-coherency/
Supports
- Compulsory, capacity, and conflict miss classification
- Coherence needs when several processors cache shared data
- https://notes.cs61c.org/content/vm/
Supports
- Virtual and physical address spaces, pages, page tables, and isolation
- Main memory as a cache for storage-backed data
- Distinction between cache hierarchy and virtual-memory mechanisms
- https://notes.cs61c.org/content/vm/memory-hierarchy-full/
Supports
- TLB and page-table translation integrated with cache lookup
- Full request path from virtual address to physical memory
- https://www.intel.com/content/www/us/en/developer/articles/technical/intel64-and-ia32-architectures-optimization.html
Supports
- Implementation-specific cache, memory, prefetch, and performance guidance
- Need to consult processor-specific documentation for tuning
- Product documentation path for Intel VTune-oriented memory analysis
- https://docs.kernel.org/core-api/real-time/hardware.html
Supports
- Caches and main memory as shared resources
- Cache contention, cache misses, cache-to-cache issues, and Linux perf measurement
- Workload interference through memory and buses
- https://docs.kernel.org/mm/numa.html
Supports
- NUMA nodes, local and remote memory, interconnect distance, latency, and bandwidth
- Local allocation, scheduling, affinity, and page-placement considerations
- Hardware cache coherence in ccNUMA systems
- https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/extended-system-coherency---part-1---cache-coherency-fundamentals
Supports
- Stale cached copies, line cleaning, invalidation, and hardware or software coherence
- Sharing data between processors and other bus masters
- Difference between cache visibility work and application synchronization
- https://developer.arm.com/-/media/Files/downloads/research/Research%20Enablement%20Kits/System%20modeling%20using%20gem5/gem5_rsk.pdf?revision=d4f12030-bdca-4db5-bfa3-b36e15dc49e7
Supports
- TLB as a cache of recent page translations
- Translation entries containing addresses, attributes, and permissions
- https://docs.riscv.org/reference/isa/unpriv/mm-eplan.html
Supports
- Separation of architectural memory ordering from a specific cache hierarchy
- Coherent and non-coherent implementations under a software-visible memory model
- https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2023-0/memory-access-analysis.html
Supports
- Intel VTune memory analysis for cache misses, NUMA, bandwidth, and memory objects
- L1, L2, L3, DRAM, and remote-access performance metrics
- Intel VTune placement in the memory-analysis tool landscape
- https://docs.amd.com/r/en-US/57368-uProf-user-guide/Cache-Analysis-Using-GUI
Supports
- AMD uProf cache-line sampling and cache-analysis reports
- AMD uProf placement in the memory-analysis tool landscape
- https://valgrind.org/docs/manual/manual-intro.html
Supports
- Cachegrind as a cache and branch-prediction profiler
- Valgrind and Cachegrind placement in the software-simulation tool landscape
- https://www.gem5.org/documentation/
Supports
- gem5 cache, coherence, interconnect, and memory-system models
- gem5 as a learner destination and architecture research simulator
- https://champsim.github.io/ChampSim/master/
Supports
- ChampSim trace-driven modeling and configurable cache hierarchy
- Cache replacement, prefetcher, associativity, and memory experiments
- https://github.com/CMU-SAFARI/ramulator2
Supports
- Ramulator as a configurable cycle-accurate DRAM simulator
- DRAM standards, controller configuration, and trace-based experiments
- https://openram.org/
Supports
- OpenRAM generation of SRAM layout, netlists, timing, power, and physical-design views
- SRAM compiler role behind cache-array implementation
- https://github.com/aolofsson/awesome-opensource-hardware/blob/main/README.md
Supports
- Discovery of gem5, ChampSim, Ramulator 2.0, and OpenRAM as relevant ecosystem projects
- Curated hardware-tool and memory-project context for Awesome Links
- https://www.ias.edu/library/ecp
Supports
- The 1946 Preliminary Discussion report and its explicit memory-hierarchy framing
- Date and institutional provenance for the early hierarchy milestone
- https://www.computerhistory.org/timeline/memory-storage/
Supports
- Whirlwind core memory in 1953
- Intel 1103 DRAM adoption in 1970 and decline of magnetic core memory
- Institutional history of memory and storage technologies
- https://www.cs.manchester.ac.uk/about/history-and-heritage/
Supports
- Atlas inauguration in 1962
- Atlas as the first computer to use virtual memory
- https://www.ibm.com/history/dram
Supports
- Robert Dennard's 1966 DRAM concept and 1968 patent
- DRAM use of a transistor and capacitor with repeated refresh
- Commercial adoption of semiconductor DRAM around 1970
- https://sigops.org/s/conferences/sosp/2015/history/abstracts.html
Supports
- Atlas as a pioneer of transparent software-managed hierarchy
- IBM System 360 Model 85 as an early hardware cache demonstration in 1968
- https://libraopen.library.virginia.edu/server/api/core/bitstreams/9a576fcb-5a03-4557-a055-3539d7e9c283/content
Supports
- Wulf and McKee's 1995 publication of the memory-wall argument
- Widening processor and memory performance gap as an architecture concern
- https://computeexpresslink.org/blog/introduction-to-compute-express-link-cxl-the-cpu-to-device-interconnect-breakthrough-2313/
Supports
- CXL technology and Specification 1.0 unveiling in March 2019
- Coherent processor-to-device memory access as a newer hierarchy path
