6a:T4a6,// HIGH TEMPORAL LOCALITY: Same variable accessed repeatedly int sum = 0; for (int i = 0; i < N; i++) { sum += array[i]; // 'sum' accessed N times - excellent temporal locality } // HIGH SPATIAL LOCALITY: Sequential array access for (int i = 0; i < N; i++) { process(array[i]); // Elements accessed in order - perfect spatial locality } // POOR SPATIAL LOCALITY: Strided access for (int i = 0; i < N; i += 64) { process(array[i]); // Skipping 64 elements - poor spatial locality } // POOR TEMPORAL & SPATIAL LOCALITY: Random access for (int i = 0; i < N; i++) { int random_index = rand() % ARRAY_SIZE; process(array[random_index]); // Random access - cache-hostile } // MATRIX ACCESS: Row-major vs Column-major // In C, arrays are stored row-major (row elements are contiguous) int matrix[1000][1000]; // GOOD: Row-major traversal (matches memory layout) for (int i = 0; i < 1000; i++) for (int j = 0; j < 1000; j++) process(matrix[i][j]); // Sequential in memory // BAD: Column-major traversal (jumps across rows) for (int j = 0; j < 1000; j++) for (int i = 0; i < 1000; i++) process(matrix[i][j]); // Jumps 1000 elements each access6b:T4ee,**Why Multiple Levels?** The existence of multiple cache levels represents a series of engineering tradeoffs: **L1 Cache (First Level):** - Closest to the processor core, physically integrated into the pipeline - Split into instruction cache (L1i) and data cache (L1d) for parallel access - Optimized for latency at all costs—must respond in 1-4 cycles - Small size (32-64 KB) enables low latency but limits capacity - Uses the fastest, most expensive SRAM technology - High hit rates despite small size due to excellent temporal locality of hot code/data **L2 Cache (Second Level):** - Backup for L1 misses, still quite fast (~10-15 cycles) - Larger capacity (256 KB - 1 MB) catches data that doesn't fit in L1 - Unified (holds both instructions and data) for flexibility - Private to each core—no coherence traffic within L2 lookups - Slight latency increase allows more complex organization **L3 Cache (Third Level / Last-Level Cache):** - Shared among all cores on a chip - Much larger (8-96 MB or more in high-end server chips) - Acts as a victim cache for L2 evictions - Critical for multi-threaded workloads with shared data - Enables inter-core communication without going to main memory - Introduces coherence complexity (covered in later pages)6c:T6de,// NAIVE MATRIX MULTIPLY - Poor cache utilization void matmul_naive(double *A, double *B, double *C, int N) { for (int i = 0; i < N; i++) { for (int j = 0; j < N; j++) { double sum = 0.0; for (int k = 0; k < N; k++) { sum += A[i*N + k] * B[k*N + j]; // B[k][j] has poor spatial locality } C[i*N + j] = sum; } } } // Problem: For large N, B column access jumps N elements per iteration, // causing cache misses every access. // LOOP BLOCKED (TILED) MATRIX MULTIPLY - Much better cache utilization #define BLOCK_SIZE 64 // Chosen to fit in L1 cache void matmul_blocked(double *A, double *B, double *C, int N) { for (int ii = 0; ii < N; ii += BLOCK_SIZE) { for (int jj = 0; jj < N; jj += BLOCK_SIZE) { for (int kk = 0; kk < N; kk += BLOCK_SIZE) { // Process one block for (int i = ii; i < ii + BLOCK_SIZE && i < N; i++) { for (int j = jj; j < jj + BLOCK_SIZE && j < N; j++) { double sum = C[i*N + j]; for (int k = kk; k < kk + BLOCK_SIZE && k < N; k++) { sum += A[i*N + k] * B[k*N + j]; } C[i*N + j] = sum; } } } } } } // Benefit: Each block of B fits in cache and is reused many times // before eviction. Can achieve 5-10x speedup for large matrices! // PREFETCH HINT EXAMPLE void process_array_with_prefetch(double *data, int N) { for (int i = 0; i < N; i++) { // Prefetch data 8 iterations ahead __builtin_prefetch(&data[i + 8], 0, 3); // GCC builtin process(data[i]); } }62:{"json":{"id":"seed_6e225526f35d4af51d81ca984ed2c77b","slug":"cache-coherence","category":"Operating Systems","topic":"Cache Coherence","title":"Cache Coherence and Memory Consistency","description":"Master the intricacies of cache hierarchy design, cache line organization, write policies, the cache coherence problem in multiprocessor systems, and industry-standard coherence protocols like MESI. Understand how modern CPUs maintain memory consistency across multiple cache levels.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_6506911bda9ab17a220d25bea9e3f59d","title":"Cache Hierarchy","order":0,"content":[{"id":"opening-hook","title":"The Memory Wall Problem","content":[{"data":{"content":"Modern processors can execute billions of instructions per second. Yet, accessing main memory takes *hundreds* of processor cycles. This gap—known as the **memory wall**—is one of the most critical performance bottlenecks in computing. Without clever engineering solutions, your multi-gigahertz processor would spend most of its time waiting for data.\n\nThe solution? **Cache memory**—small, fast memories strategically placed between the processor and main memory, organized into a sophisticated **cache hierarchy** that dramatically reduces average memory access times. Understanding this hierarchy isn't just academic; it's essential for writing high-performance code and understanding why some programs run 10x faster than functionally equivalent alternatives."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete architecture of modern cache hierarchies—from L1 through L3 and beyond. You'll learn why caches are organized this way, the fundamental tradeoffs at each level, and how cache hierarchy design profoundly impacts both hardware architecture and software performance.","variant":"info"},"type":"callout"}]},{"id":"speed-gap","title":"The Processor-Memory Speed Gap","content":[{"data":{"content":"To appreciate cache hierarchies, we must first understand the problem they solve. The history of computing reveals a widening chasm between processor and memory speeds:\n\n**Historical Divergence:**\n\nIn the early 1980s, processor and memory speeds were roughly matched—both operated at a few megahertz. A processor could access memory in approximately the same time it took to execute an instruction. Life was simple.\n\nBut then the paths diverged dramatically. Processor speeds increased by roughly 60% per year through the 1990s and 2000s, driven by advances in transistor density and architecture. Memory speeds improved by only 7-10% per year, constrained by the physics of DRAM technology."},"type":"text"},{"data":{"rows":[["1980","10 MHz","150 ns","~1.5 cycles"],["1990","40 MHz","100 ns","~4 cycles"],["2000","1,000 MHz (1 GHz)","70 ns","~70 cycles"],["2010","3,000 MHz (3 GHz)","50 ns","~150 cycles"],["2020","4,500 MHz (4.5 GHz)","40 ns","~180 cycles"],["Present","5,000+ MHz (5+ GHz)","35 ns","~175-200 cycles"]],"caption":"The Widening Processor-Memory Gap Over Time","headers":["Year","Typical Processor Speed","DRAM Access Time","Speed Ratio"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The Performance Catastrophe Without Caches","content":"At 5 GHz, a single memory access taking 200 cycles means the processor sits idle for 199 cycles waiting for data. Without caches, even the fastest processor becomes a slow memory-access machine. Cache hierarchies transform this idle time into productive computation.","variant":"warning"},"type":"callout"},{"data":{"content":"**Why DRAM Can't Keep Up:**\n\nDRAM (Dynamic Random-Access Memory) stores each bit as a charge in a tiny capacitor. This design offers:\n- **High density:** Billions of bits per chip\n- **Low cost:** A few dollars per gigabyte\n- **But slow access:** Reading requires sensing tiny charges, amplifying signals, and destructively reading (which requires rewriting)\n\nMaking DRAM faster requires shrinking capacitors, which reduces charge and increases error rates. Physics imposes fundamental limits on DRAM speed improvements.\n\n**SRAM: The Alternative**\n\nStatic RAM (SRAM) stores bits using flip-flop circuits—six transistors per bit instead of one transistor and one capacitor. SRAM offers:\n- **Very fast access:** 1-2 ns\n- **No refresh needed:** Stable as long as power is applied\n- **But low density:** 6x more transistors per bit\n- **And high cost:** 10-20x more expensive per bit than DRAM\n\nWe can't build gigabytes of SRAM economically—but we can strategically place small amounts where they matter most."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"locality","title":"The Principle of Locality","content":[{"data":{"content":"Caches work because of a fundamental property of programs: **locality of reference**. Programs don't access memory randomly; they exhibit predictable patterns that caches exploit.\n\n**Two Dimensions of Locality:**"},"type":"text"},{"data":{"left":[{"data":{"items":["**Definition:** Recently accessed data is likely to be accessed again soon","**Examples:** Loop counters, frequently-used variables, function call return addresses","**Exploitation:** Keep recently accessed data in cache, evict old data when space is needed","**Impact:** A single cache fetches data once and serves multiple subsequent accesses"],"title":{"icon":"Target","text":"Temporal Locality","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Definition:** Data near recently accessed data is likely to be accessed soon","**Examples:** Array traversal, sequential instruction fetch, struct field access","**Exploitation:** Fetch blocks of data (cache lines), not individual bytes","**Impact:** One memory access brings in useful neighboring data 'for free'"],"title":{"icon":"Zap","text":"Spatial Locality","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"**Quantifying Locality:**\n\nEmpirical studies consistently show that typical programs spend:\n- 90% of their execution time in just 10% of their code\n- 80% of memory references hit the same 20% of addresses (within short time windows)\n\nThis concentration of access makes caching viable. If every memory access were random, caches would be useless—we'd never find the data we need in the cache.\n\n**Locality in Different Program Patterns:**"},"type":"text"},{"data":{"code":"$6a","fileName":"locality_examples.c","languages":[{"label":"C","value":"c"}]},"type":"code"},{"data":{"icon":"Lightbulb","title":"The Matrix Traversal Difference","content":"The row-major vs column-major traversal difference can cause 10-50x performance differences for large matrices. The 'wrong' order thrashes the cache, turning a memory-bound problem into a cache-miss nightmare. Understanding cache hierarchy makes this obvious; without it, the performance difference seems mysterious.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"multi-level-cache","title":"Multi-Level Cache Architecture","content":[{"data":{"content":"Modern processors don't use a single cache—they employ a **hierarchy** of caches, each level trading off speed, size, and proximity to the processor. This design emerges from the insight that a single cache can't simultaneously be fast, large, and practical.\n\n**The Classic Three-Level Hierarchy:**"},"type":"text"},{"data":{"rows":[["L1 Instruction","32-64 KB","~1-4 cycles (1-2 ns)","SRAM","Private per core"],["L1 Data","32-64 KB","~1-4 cycles (1-2 ns)","SRAM","Private per core"],["L2 Unified","256 KB - 1 MB","~10-15 cycles (5-7 ns)","SRAM","Private per core"],["L3 Unified","8-96 MB (total)","~30-50 cycles (15-25 ns)","SRAM","Shared across cores"],["Main Memory","16-128 GB","~150-200 cycles (50-100 ns)","DRAM","Shared system-wide"]],"caption":"Modern Cache Hierarchy Characteristics (Typical Desktop/Server CPU, 2024)","headers":["Cache Level","Size (per core)","Access Latency","Technology","Sharing"]},"type":"table"},{"data":{"content":"$6b"},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"flowchart TB\n subgraph Core1[\"CPU Core 1\"]\n L1I1[\"L1i Cache\n32KB\n~2 cycles\"]\n L1D1[\"L1d Cache\n32KB\n~2 cycles\"]\n end\n subgraph Core2[\"CPU Core 2\"]\n L1I2[\"L1i Cache\n32KB\n~2 cycles\"]\n L1D2[\"L1d Cache\n32KB\n~2 cycles\"]\n end\n subgraph Core3[\"CPU Core N\"]\n L1I3[\"L1i Cache\n32KB\n~2 cycles\"]\n L1D3[\"L1d Cache\n32KB\n~2 cycles\"]\n end\n \n L2_1[\"L2 Cache\n512KB\n~12 cycles\"]\n L2_2[\"L2 Cache\n512KB\n~12 cycles\"]\n L2_3[\"L2 Cache\n512KB\n~12 cycles\"]\n \n L3[\"L3 Cache (Shared)\n16MB\n~40 cycles\"]\n \n MEM[\"Main Memory (DRAM)\n32GB\n~200 cycles\"]\n \n L1I1 --> L2_1\n L1D1 --> L2_1\n L1I2 --> L2_2\n L1D2 --> L2_2\n L1I3 --> L2_3\n L1D3 --> L2_3\n \n L2_1 --> L3\n L2_2 --> L3\n L2_3 --> L3\n \n L3 --> MEM"},"type":"mermaid-excalidraw"}],"titleType":"number","titleNumber":3},{"id":"inclusion-policies","title":"Inclusion Policies: Inclusive, Exclusive, and NINE","content":[{"data":{"content":"An important design decision in multi-level caches is the **inclusion policy**: the relationship between what data exists at different cache levels."},"type":"text"},{"data":{"items":["**Inclusive Cache:** Every block in L1 is also present in L2 (and L3). L2 is a superset of L1. **Pros:** Simple coherence checking—only check L2/L3 to see if a core has data. **Cons:** Wastes space—the same data occupies multiple cache levels.","**Exclusive Cache:** A block exists in only ONE cache level at a time. Data promoted from L2 to L1 is removed from L2; data evicted from L1 goes to L2. **Pros:** Maximum effective capacity—no replication. **Cons:** Coherence checking must probe all levels; more complex.","**Non-Inclusive Non-Exclusive (NINE):** No strict enforcement. A block in L1 may or may not be in L2. **Pros:** Flexibility, simpler than exclusive. **Cons:** Coherence complexity; must track data location explicitly."],"title":{"icon":"BookOpen","text":"Inclusion Policy Types","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"rows":[["Effective Capacity","Lower (duplication)","Maximum (no duplication)","Moderate"],["Coherence Simplicity","Simple (check higher level)","Complex (check all levels)","Moderate"],["Back-Invalidation","Yes (L2 eviction invalidates L1)","No","No"],["Implementation Complexity","Moderate","Higher","Lower"],["Used In","Intel (older), some ARM","AMD, some Intel L2-L3","Intel (newer L3)"]],"caption":"Comparison of Inclusion Policies","headers":["Aspect","Inclusive","Exclusive","NINE"]},"type":"table"},{"data":{"content":"**Intel's Evolution:**\n\nIntel traditionally used inclusive L3 caches because it simplified coherence—to check if any core has a cache line, you only need to check the L3. If it's not there, no core has it.\n\nHowever, inclusive caches suffer from **back-invalidation**: when L3 evicts a line, it must also invalidate that line in any L1/L2 cache that holds it. With growing core counts and relatively smaller L3 per core, this became problematic.\n\nStarting with Skylake-SP and Coffee Lake, Intel moved to NINE L3 caches, accepting the coherence complexity for better effective capacity.\n\n**AMD's Approach:**\n\nAMD has used exclusive or NINE caches for longer, particularly between L2 and L3. This maximizes cache capacity at the cost of more complex coherence tracking."},"type":"text"},{"data":{"icon":"Info","title":"Operating System Implications","content":"Operating systems don't typically need to know inclusion policies—hardware handles this transparently. However, OS developers and performance engineers benefit from understanding these tradeoffs when analyzing cache behavior and designing cache-aware data structures.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"beyond-l3","title":"Beyond L3: L4, eDRAM, and Emerging Technologies","content":[{"data":{"content":"The three-level hierarchy isn't universal. Some processors add L4 caches or use hybrid technologies:\n\n**L4 Cache (eDRAM):**\n\nIntel introduced L4 caches in some Haswell and Broadwell processors (Iris Pro graphics) using **embedded DRAM (eDRAM)**:\n- Integrated on the same package as the CPU (but separate die)\n- 128 MB capacity—much larger than any L3\n- Slower than SRAM L3 (~50-60 cycles) but faster than main memory\n- Primarily served integrated graphics but helped CPU workloads too\n- Discontinued in later processors as integrated graphics improved\n\n**3D V-Cache (AMD):**\n\nAMD's 3D V-Cache technology stacks additional SRAM cache directly on top of existing L3:\n- Up to 96 MB additional L3 (192 MB total on some chips)\n- Uses 3D chip-stacking technology\n- Minimal latency increase (same SRAM technology)\n- Significant performance gains for cache-sensitive workloads (gaming, some HPC)"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Performance Impact of More Cache","content":"AMD's 3D V-Cache demonstrates how dramatic cache capacity effects can be. The Ryzen 7 5800X3D with 96 MB L3 outperforms the higher-clocked 5800X in many games by 10-15%, despite lower clock speeds. When working sets fit in cache, even modest capacity increases eliminate expensive memory accesses.","variant":"tip"},"type":"callout"},{"data":{"content":"**Emerging Technologies:**\n\n**Non-Volatile Memory (NVM) as Cache:**\nIntel's Optane (3D XPoint) technology briefly served as a large, persistent cache tier between DRAM and SSD. While discontinued, the concept of tiered memory with different performance characteristics continues to evolve.\n\n**Compute Express Link (CXL):**\nCXL enables memory expansion and pooling, creating new cache hierarchy considerations. Future systems may have:\n- Local DRAM (fast)\n- CXL-attached memory (slower, expandable)\n- Caches may need to account for NUMA-like effects at the memory level\n\n**Smart Caches in Accelerators:**\nGPUs and AI accelerators have their own cache hierarchies optimized for massively parallel workloads. These often feature:\n- Very large shared caches (or scratchpads)\n- Software-managed cache behavior\n- Coherence domains that differ from CPU caches"},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"performance-analysis","title":"Cache Hierarchy Performance Analysis","content":[{"data":{"content":"Understanding cache hierarchy performance requires quantifying the impact of cache hits and misses at each level.\n\n**Average Memory Access Time (AMAT):**\n\nThe fundamental equation for cache performance is:\n\n```\nAMAT = T_hit + (Miss_Rate × Miss_Penalty)\n```\n\nFor a multi-level hierarchy, this extends recursively:\n\n```\nAMAT = T_L1 + (MR_L1 × [T_L2 + (MR_L2 × [T_L3 + (MR_L3 × T_Memory)])])\n```\n\nWhere:\n- `T_Lx` = Hit time at level x\n- `MR_Lx` = Miss rate at level x (fraction of accesses that miss)\n- `T_Memory` = Main memory access time"},"type":"text"},{"data":{"title":"Calculating AMAT for a Three-Level Hierarchy","content":"Given:\n- L1: 2 cycle hit time, 5% miss rate\n- L2: 12 cycle hit time, 20% miss rate (of L1 misses)\n- L3: 40 cycle hit time, 30% miss rate (of L2 misses)\n- Memory: 200 cycle access time\n\nCalculation:\nAMAT = 2 + 0.05 × [12 + 0.20 × [40 + 0.30 × 200]]\n = 2 + 0.05 × [12 + 0.20 × [40 + 60]]\n = 2 + 0.05 × [12 + 0.20 × 100]\n = 2 + 0.05 × [12 + 20]\n = 2 + 0.05 × 32\n = 2 + 1.6\n = 3.6 cycles\n\nInterpretation:\nDespite L1 having only 95% hit rate, the effective memory access time\nis just 3.6 cycles—not 200 cycles. The cache hierarchy reduces average\nmemory access time by 98.2%!\n\nWithout caches:\nEffective access time = 200 cycles (every access goes to memory)\n\nSpeedup from caches: 200 / 3.6 = 55.6x improvement","description":"Consider a system with the following parameters:"},"type":"example"},{"data":{"content":"**Global vs Local Miss Rates:**\n\nTwo ways to express cache miss rates:\n\n**Local Miss Rate:** Fraction of accesses to this cache level that miss\n- L2 local miss rate = L2 misses / L2 accesses\n- Useful for understanding individual cache effectiveness\n\n**Global Miss Rate:** Fraction of total memory references that miss a given level\n- L2 global miss rate = L2 misses / Total CPU memory references\n- Useful for understanding overall system behavior\n\n**Relationship:** Global Miss Rate = L1 Miss Rate × L2 Local Miss Rate"},"type":"text"},{"data":{"rows":[["**Compulsory (Cold)**","First access to a block; unavoidable cache miss","Increase cache line size (prefetch more data); use software prefetching"],["**Capacity**","Cache too small to hold all needed blocks","Increase cache size; improve data structure locality; blocking/tiling algorithms"],["**Conflict**","Multiple blocks map to same cache set (associativity limit)","Increase associativity; use better placement/replacement policies"],["**Coherence**","Invalidation due to another processor's write (multiprocessor)","Reduce sharing; use synchronization carefully; false sharing avoidance"]],"caption":"Miss Rate Classification","headers":["Miss Type","Definition","How to Reduce"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"The 3 Cs (and 4th C) of Cache Misses","content":"Compulsory, Capacity, and Conflict misses are the classic '3 Cs' of cache misses. In multiprocessor systems, Coherence misses become the '4th C.' Performance optimization requires identifying which miss type dominates and addressing it specifically—bigger caches won't help compulsory misses, and higher associativity won't help capacity misses.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"cache-aware-programming","title":"Cache-Aware Programming","content":[{"data":{"content":"Software developers can dramatically improve performance by understanding cache hierarchy. Here are practical techniques:"},"type":"text"},{"data":{"items":["**Loop Blocking (Tiling):** Break large loops into cache-sized chunks. Process a block completely before moving to the next, keeping working set in cache.","**Data Structure Layout:** Store frequently co-accessed data together. Use arrays of structs vs structs of arrays depending on access patterns.","**Loop Interchange:** Reorder nested loops to access memory in the order it's stored (row-major for C/C++, column-major for Fortran).","**Prefetching:** Hint to hardware to load data before it's needed. Software prefetch intrinsics or compiler directives can help.","**Avoid False Sharing:** In multithreaded code, ensure different threads don't modify data in the same cache line (covered in later pages)."],"title":{"icon":"Code2","text":"Cache Optimization Techniques","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"code":"$6c","fileName":"loop_blocking_example.c","languages":[{"label":"C","value":"c"}]},"type":"code"},{"data":{"icon":"CheckCircle","title":"Real-World Impact","content":"Loop blocking is used extensively in high-performance linear algebra libraries (BLAS, LAPACK) and can achieve 80-90% of theoretical peak performance. Understanding cache hierarchy transforms naive code achieving 5% of peak into optimized code approaching hardware limits.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: Cache Hierarchy","content":[{"data":{"content":"We've covered the foundational concepts of cache hierarchy. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**The memory wall is real** — Processors are 100-200x faster than main memory. Without caches, modern CPUs would be crippled by memory latency.","**Locality makes caching work** — Temporal and spatial locality ensure that small, fast caches can service the vast majority of memory accesses.","**Multi-level hierarchies balance tradeoffs** — L1 optimizes for speed, L3 for capacity, with L2 bridging the gap. Each level serves a purpose.","**Inclusion policies matter** — Inclusive, exclusive, and NINE caches offer different tradeoffs between capacity efficiency and coherence simplicity.","**Cache technology evolves** — From eDRAM L4 to 3D V-Cache, hardware architects continue pushing cache capacity and performance.","**AMAT quantifies performance** — Average Memory Access Time calculations reveal the compound benefit of the cache hierarchy.","**Software can leverage cache** — Loop blocking, data layout, and prefetching can yield order-of-magnitude performance improvements."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand the cache hierarchy structure, the next page dives into **Cache Lines**—the fundamental unit of data transfer between cache levels. We'll explore how cache lines are addressed, organized, and why their size profoundly affects both hardware design and software performance."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand modern multi-level cache hierarchies and their critical role in bridging the processor-memory gap. Next, we'll examine cache lines—the building blocks that make cache operation possible.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_7140d174d083d7fed8afc774baa83fc9","title":"Cache Lines","order":1,"content":null,"isLocked":true},{"id":"seed_2100afb79c8c3356bb0ac14237480ec3","title":"Write-Through vs Write-Back","order":2,"content":null,"isLocked":true},{"id":"seed_6a1ffdaa1721da5cb8f318ddbb941e3a","title":"Cache Coherence Problem","order":3,"content":null,"isLocked":true},{"id":"seed_c426a78629c5ea5b4efb979d521deadc","title":"Coherence Protocols (MESI)","order":4,"content":null,"isLocked":true}]}}