69:T7a8,#include #include #include #include #define SIZE (1024 * 1024 * 256) // 256 MB #define ITERATIONS 100000000 // Benchmark memory access latency on different NUMA nodes void benchmark_numa_latency(int allocation_node, int execution_node) { // Bind thread to specified node struct bitmask *nodemask = numa_bitmask_alloc(numa_max_node() + 1); numa_bitmask_setbit(nodemask, execution_node); numa_run_on_node_mask(nodemask); // Allocate memory on specified node char *buffer = numa_alloc_onnode(SIZE, allocation_node); if (!buffer) { fprintf(stderr, "NUMA allocation failed "); return; } // Initialize (page fault to materialize pages) for (size_t i = 0; i < SIZE; i += 4096) { buffer[i] = 0; } // Benchmark random access struct timespec start, end; clock_gettime(CLOCK_MONOTONIC, &start); volatile char sum = 0; unsigned int seed = 42; for (long i = 0; i < ITERATIONS; i++) { size_t index = rand_r(&seed) % SIZE; sum += buffer[index]; // Random read } clock_gettime(CLOCK_MONOTONIC, &end); double elapsed_ns = (end.tv_sec - start.tv_sec) * 1e9 + (end.tv_nsec - start.tv_nsec); double latency_ns = elapsed_ns / ITERATIONS; printf("Alloc Node %d, Exec Node %d: %.2f ns/access ", allocation_node, execution_node, latency_ns); numa_free(buffer, SIZE); numa_bitmask_free(nodemask); } int main() { if (numa_available() < 0) { fprintf(stderr, "NUMA not available "); return 1; } int max_node = numa_max_node(); printf("NUMA nodes: 0-%d ", max_node); // Test all combinations for (int alloc = 0; alloc <= max_node; alloc++) { for (int exec = 0; exec <= max_node; exec++) { benchmark_numa_latency(alloc, exec); } } return 0; }62:{"json":{"id":"seed_4fd83accdb3ec2723fb71d58305737dd","slug":"numa-architecture","category":"Operating Systems","topic":"NUMA Architecture","title":"NUMA Architecture","description":"Master Non-Uniform Memory Access (NUMA) architecture, understanding how modern multiprocessor systems organize memory access across multiple processor sockets, and how operating systems optimize memory placement for performance-critical applications.","difficulty":"ADVANCED","estimatedMinutes":60,"pages":[{"id":"seed_b69dc8529e2b0fe2c02264a4883a7f0c","title":"Non-Uniform Memory Access","order":0,"content":[{"id":"opening-hook","title":"When Memory Access Time Isn't Equal","content":[{"data":{"content":"In the early days of multiprocessor computing, a comforting assumption prevailed: every processor could access any memory location in approximately the same time. This **Uniform Memory Access (UMA)** model simplified programming and operating system design. But as systems grew beyond a single processor socket—scaling to 2, 4, 8, or even hundreds of cores—this assumption became not just inaccurate, but **catastrophically misleading**.\n\nWelcome to the world of **Non-Uniform Memory Access (NUMA)**, where the physical reality of silicon, copper traces, and interconnects forces us to confront an uncomfortable truth: **memory access time depends on which processor is doing the accessing and which memory bank contains the data**."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand why NUMA exists, how it fundamentally differs from symmetric multiprocessing, and why operating system designers must be acutely aware of memory topology. You'll grasp the physics and engineering constraints that make NUMA inevitable in large-scale systems, and the profound implications for software performance.","variant":"info"},"type":"callout"}]},{"id":"smp-to-numa-evolution","title":"The Evolution from SMP to NUMA","content":[{"data":{"content":"To understand NUMA, we must first understand what it replaced and why the transition became necessary. The story begins with **Symmetric Multiprocessing (SMP)**, also known as **Uniform Memory Access (UMA)**.\n\n**The SMP/UMA Architecture:**\n\nIn an SMP system, all processors share a common memory bus and can access all memory with identical latency. The memory controller sits between processors and memory, arbitrating access transparently. From a programmer's perspective, memory is memory—there's no distinction between 'near' and 'far' memory because all memory is equidistant from all processors.\n\nThis architecture dominated the 1990s and early 2000s. Dual-socket and quad-socket servers used SMP successfully because the number of processors was small enough that bus bandwidth could keep up with aggregate memory demand."},"type":"text"},{"data":{"height":"400px","mermaidSyntax":"graph TB\n subgraph \"SMP/UMA Architecture\"\n CPU1[CPU 1]\n CPU2[CPU 2]\n CPU3[CPU 3]\n CPU4[CPU 4]\n \n BUS[Shared Memory Bus]\n MC[Memory Controller]\n \n MEM1[DRAM Bank 1]\n MEM2[DRAM Bank 2]\n MEM3[DRAM Bank 3]\n MEM4[DRAM Bank 4]\n \n CPU1 --> BUS\n CPU2 --> BUS\n CPU3 --> BUS\n CPU4 --> BUS\n \n BUS --> MC\n \n MC --> MEM1\n MC --> MEM2\n MC --> MEM3\n MC --> MEM4\n end\n \n style BUS fill:#ff6b6b,stroke:#c92a2a,color:#fff\n style MC fill:#339af0,stroke:#1864ab,color:#fff"},"type":"mermaid-excalidraw"},{"data":{"icon":"AlertCircle","title":"The Scalability Wall","content":"The shared bus in SMP systems becomes a catastrophic bottleneck as processor count increases. With 4 processors, bus contention is manageable. With 8, it's problematic. With 16 or more, the bus becomes so saturated that adding more processors actually *decreases* performance. This phenomenon is called 'negative scaling.'","variant":"warning"},"type":"callout"},{"data":{"content":"**The Physics Problem:**\n\nSeveral fundamental physical constraints doom SMP at scale:\n\n1. **Bus Bandwidth Saturation**: Each processor can issue memory requests at modern DRAM speeds. A shared bus must handle the aggregate bandwidth of all processors. With more cores, the bus becomes the bottleneck.\n\n2. **Signal Propagation Delays**: Electrical signals travel at roughly 1 foot per nanosecond in copper. As systems grow physically larger to accommodate more processors and memory, signal propagation itself introduces latency.\n\n3. **Cache Coherency Traffic**: In SMP, when one processor modifies data, all other processors with cached copies must be notified. This coherency traffic consumes bus bandwidth and increases with processor count.\n\n4. **Memory Controller Contention**: A single memory controller must serialize all memory requests. This serialization overhead grows non-linearly with processor count.\n\nBy the mid-2000s, these constraints forced a fundamental architectural rethinking. The result was NUMA."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"what-numa-is","title":"What NUMA Actually Is","content":[{"data":{"content":"**Non-Uniform Memory Access (NUMA)** is a memory architecture where the time to access memory depends on the memory's location relative to the accessing processor. Some memory is 'local' (attached directly to the processor's memory controller) and some is 'remote' (attached to another processor's memory controller).\n\n**The Core Principle:**\n\nIn NUMA, each processor (or group of processors) has its own **local memory** connected via a dedicated memory controller. Processors can still access memory attached to other processors, but this requires traversing an **interconnect** (such as Intel's QPI/UPI or AMD's Infinity Fabric), which introduces additional latency."},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"graph TB\n subgraph \"NUMA Node 0\"\n CPU0[CPU 0\n8 cores]\n MC0[Memory Controller 0]\n MEM0[Local DRAM\n64 GB]\n \n CPU0 --> MC0\n MC0 --> MEM0\n end\n \n subgraph \"NUMA Node 1\"\n CPU1[CPU 1\n8 cores]\n MC1[Memory Controller 1]\n MEM1[Local DRAM\n64 GB]\n \n CPU1 --> MC1\n MC1 --> MEM1\n end\n \n INTER[High-Speed Interconnect\nQPI / UPI / Infinity Fabric]\n \n CPU0 <---> INTER\n CPU1 <---> INTER\n \n style INTER fill:#ffd43b,stroke:#f59f00,color:#000\n style MEM0 fill:#69db7c,stroke:#2b8a3e\n style MEM1 fill:#69db7c,stroke:#2b8a3e"},"type":"mermaid-excalidraw"},{"data":{"content":"**Understanding Memory Access Latency in NUMA:**\n\nConsider a dual-socket server where CPU 0 needs to access data:"},"type":"text"},{"data":{"rows":[["Local (Node 0)","CPU 0 → MC 0 → DRAM 0","~80 ns"],["Remote (Node 1)","CPU 0 → Interconnect → MC 1 → DRAM 1","~150 ns"]],"headers":["Memory Location","Access Path","Typical Latency"]},"type":"table"},{"data":{"content":"The remote access is nearly **2x slower** than local access. This ratio is called the **NUMA ratio** or **remote-to-local latency ratio**. In real systems, NUMA ratios typically range from 1.5x to 3x, depending on the number of hops through the interconnect."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The NUMA Guarantee","content":"Despite the non-uniform access times, NUMA systems guarantee that all memory is accessible from all processors. This is crucial—it means existing programs 'just work' on NUMA systems. They might work *slowly* if memory is poorly placed, but they won't crash or produce incorrect results. NUMA is transparent to correctness, but critical to performance.","variant":"tip"},"type":"callout"},{"data":{"content":"**Why NUMA Enables Scalability:**\n\nNUMA solves SMP's scalability problems by distributing the memory system:\n\n1. **Distributed Memory Controllers**: Each processor has its own memory controller. No single controller bottlenecks all memory access.\n\n2. **Local Bandwidth Isolation**: A processor accessing local memory doesn't compete with other processors for bandwidth (except for cache coherency traffic).\n\n3. **Scalable Interconnect**: Modern interconnects like AMD's Infinity Fabric or Intel's UPI use point-to-point links rather than shared buses. Adding more sockets doesn't degrade existing connections.\n\n4. **Aggregate Bandwidth Growth**: Total system memory bandwidth scales with socket count. A 4-socket NUMA system has ~4x the memory bandwidth of a single socket.\n\nThis architecture enables systems with hundreds of cores and terabytes of memory—something fundamentally impossible with SMP."},"type":"text"}],"titleType":"number","titleNumber":2},{"id":"numa-topology-distance","title":"NUMA Topology and Distance","content":[{"data":{"content":"In simple two-socket systems, NUMA is straightforward: memory is either local or one hop away. But modern high-end systems can have 4, 8, or even 16 sockets, creating complex **NUMA topologies** where some remote memory is 'closer' than other remote memory.\n\n**NUMA Distance:**\n\nOperating systems model NUMA topology using a concept called **NUMA distance**—a relative measure of access latency between NUMA nodes. The ACPI SLIT (System Locality Information Table) provides this information to the OS.\n\nBy convention:\n- Local access has distance **10**\n- Remote access has distance **20** or higher\n- Actual values vary by system and represent relative latency, not absolute time"},"type":"text"},{"data":{"fileName":"numa-distance-query.sh","languages":[{"code":"# View NUMA topology on Linux\nnumactl --hardware\n\n# Sample output for a 4-socket system:\n# available: 4 nodes (0-3)\n# node 0 cpus: 0-15\n# node 0 size: 65536 MB\n# node 0 free: 48120 MB\n# node 1 cpus: 16-31\n# node 1 size: 65536 MB\n# node 1 free: 51234 MB\n# node 2 cpus: 32-47\n# node 2 size: 65536 MB\n# node 2 free: 49876 MB\n# node 3 cpus: 48-63\n# node 3 size: 65536 MB\n# node 3 free: 52012 MB\n# node distances:\n# node 0 1 2 3\n# 0: 10 21 31 21\n# 1: 21 10 21 31\n# 2: 31 21 10 21\n# 3: 21 31 21 10\n\n# Query distance programmatically\ncat /sys/devices/system/node/node0/distance\n# Output: 10 21 31 21","label":"Bash","value":"bash"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**Interpreting the Distance Matrix:**\n\nIn the example above, we see a 4-socket system with an interesting topology:"},"type":"text"},{"data":{"rows":[["Node 0","10 (local)","21","31","21"],["Node 1","21","10 (local)","21","31"],["Node 2","31","21","10 (local)","21"],["Node 3","21","31","21","10 (local)"]],"headers":["From Node","To Node 0","To Node 1","To Node 2","To Node 3"]},"type":"table"},{"data":{"content":"This reveals a **linear or ring topology**: Node 0 has fast access to Nodes 1 and 3 (one hop, distance 21), but slower access to Node 2 (two hops, distance 31). The OS must understand this topology to make intelligent memory placement decisions."},"type":"text"},{"data":{"height":"350px","mermaidSyntax":"graph LR\n subgraph \"4-Socket NUMA Topology\"\n N0[Node 0] <--\"1 hop\ndist: 21\"--> N1[Node 1]\n N1 <--\"1 hop\ndist: 21\"--> N2[Node 2]\n N2 <--\"1 hop\ndist: 21\"--> N3[Node 3]\n N3 <--\"1 hop\ndist: 21\"--> N0\n \n N0 <--\"2 hops\ndist: 31\"--> N2\n N1 <--\"2 hops\ndist: 31\"--> N3\n end\n \n style N0 fill:#339af0,stroke:#1864ab,color:#fff\n style N1 fill:#69db7c,stroke:#2b8a3e\n style N2 fill:#ffd43b,stroke:#f59f00\n style N3 fill:#ff8787,stroke:#c92a2a"},"type":"mermaid-excalidraw"},{"data":{"icon":"Info","title":"Why Topology Matters","content":"When the OS needs to allocate memory remotely (because local memory is full), knowing the topology lets it choose the *nearest* remote node. Allocating on Node 1 from Node 0 (distance 21) is much better than allocating on Node 2 (distance 31). A 47% latency difference can translate to significant performance differences for memory-bound applications.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"hardware-implementations","title":"Hardware Implementations of NUMA","content":[{"data":{"content":"NUMA is not an abstract concept—it's implemented in concrete silicon. Understanding the major hardware implementations helps appreciate why NUMA behaves the way it does.\n\n**Intel's Implementation: QPI and UPI**\n\nIntel's multi-socket Xeon processors use **QuickPath Interconnect (QPI)**, replaced by **Ultra Path Interconnect (UPI)** in newer Xeon Scalable processors. These are high-speed point-to-point links that connect processor sockets.\n\n- **Bandwidth**: UPI provides 10.4 GT/s per link in 3rd gen Xeon Scalable\n- **Links per socket**: Typically 2-3 UPI links per processor\n- **Latency**: ~10-15 ns added per hop\n- **Cache Coherency**: UPI carries both data and coherency traffic"},"type":"text"},{"data":{"rows":[["Intel","UPI (Ultra Path Interconnect)","10.4 GT/s","Integrated memory controller, 3 links per Xeon Max"],["AMD","Infinity Fabric","~36 GB/s bidirectional","Scalable to 8+ sockets, CCX awareness"],["IBM","PowerAXON","~60 GB/s","Large socket counts, memory buffer chips"],["ARM","CCIX/CXL","Variable","Open standard, emerging in datacenter"]],"caption":"NUMA Interconnect Comparison","headers":["Vendor","Interconnect","Bandwidth","Notable Features"]},"type":"table"},{"data":{"content":"**AMD's Implementation: Infinity Fabric**\n\nAMD's EPYC processors use **Infinity Fabric**, a highly scalable interconnect with an interesting property: NUMA exists **within a single socket**.\n\nEPYC processors are composed of multiple chiplets (CCDs), each containing a subset of cores. Memory is attached to a central I/O die, but different CCDs have different distances to different memory channels. This creates **multiple NUMA nodes per socket**—a 64-core EPYC might expose 8 NUMA nodes.\n\nThis design choice reflects a fundamental tradeoff:\n- **More NUMA domains** = more complex memory placement\n- **But** enables AMD to build larger processors from smaller, higher-yield chiplets"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Sub-NUMA Clustering (SNC)","content":"Intel also offers Sub-NUMA Clustering (SNC) on Xeon Scalable, which divides a single socket into 2 NUMA nodes. This reduces average local memory latency but increases NUMA complexity. BIOS settings control whether SNC is enabled—sysadmins must understand the performance implications.","variant":"warning"},"type":"callout"},{"data":{"content":"**Cache Coherency in NUMA:**\n\nNUMA systems must maintain **cache coherency**—ensuring that all processors see consistent values for shared memory locations. This is challenging because:\n\n1. Each processor has its own cache hierarchy (L1, L2, L3)\n2. The same memory location might be cached on multiple sockets\n3. Writes must invalidate or update remote copies\n\nModern NUMA systems use **directory-based coherency protocols** where a 'home node' (usually where the memory is physically located) tracks which caches hold copies of each cache line. This is more scalable than broadcast-based snooping used in SMP.\n\n**The coherency tax:**\n\nWhen data is shared and modified across NUMA nodes, the coherency traffic eats into interconnect bandwidth. This creates an additional performance cliff beyond pure memory access latency—heavily shared, frequently modified data suffers worse performance than data accessed by a single node."},"type":"text"}],"titleType":"number","titleNumber":4},{"id":"numa-performance-cliff","title":"The NUMA Performance Cliff","content":[{"data":{"content":"NUMA introduces a fundamental performance asymmetry that can cause dramatic performance degradation—or dramatic improvements—depending on memory placement. Understanding this 'performance cliff' is essential for systems engineering.\n\n**Quantifying the Impact:**\n\nConsider a memory-bound application performing random reads across a working set that exceeds cache. On a typical modern server:"},"type":"text"},{"data":{"rows":[["L3 Cache Hit","~15 ns","1.0x (baseline)"],["Local DRAM Access","~80 ns","0.19x"],["Remote DRAM (1 hop)","~150 ns","0.10x"],["Remote DRAM (2 hops)","~200 ns","0.075x"]],"caption":"Memory Access Latency Impact","headers":["Access Pattern","Latency","Relative Performance"]},"type":"table"},{"data":{"content":"**The Multiplicative Effect:**\n\nIf an application's memory is entirely misplaced on a remote node:\n\n1. Every memory access pays the remote penalty\n2. Throughput drops by 40-50% for memory-bound workloads\n3. Tail latencies (P99, P99.9) explode due to interconnect congestion\n4. Other applications sharing the interconnect also suffer\n\nThis isn't theoretical. Production databases, in-memory caches, and high-frequency trading systems regularly see these degradations when NUMA is ignored."},"type":"text"},{"data":{"fileName":"numa-benchmark.c","languages":[{"code":"$69","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"The Hidden NUMA Trap","content":"The most insidious NUMA performance problem is silent degradation. Applications don't crash or throw errors when memory is remote—they just run slowly. Without explicit NUMA metrics, teams blame 'the network' or 'the database' when the real culprit is memory placement. Always monitor NUMA metrics (local vs. remote access counters) on multi-socket systems.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"numa-design-principles","title":"First Principles of NUMA Design","content":[{"data":{"content":"Now that we understand what NUMA is and why it matters, let's establish the foundational principles that guide all NUMA-aware system design.\n\n**Principle 1: Locality is Everything**\n\nThe single most important optimization in NUMA systems is ensuring data is placed in memory local to the processor that will access it. This sounds simple, but requires:\n\n- Understanding which threads access which data\n- Ensuring memory allocation happens on the correct node\n- Preventing the OS or other processes from migrating pages"},"type":"text"},{"data":{"items":["**Collocate Threads and Data** — Threads should execute on the same NUMA node as the memory they access. Pin critical threads and use NUMA-aware allocation.","**Partition by Node, Not by Thread** — Design data structures that can be cleanly partitioned across NUMA nodes, with each partition owned by threads on that node.","**Minimize Cross-Node Traffic** — When data must be shared across nodes, batch updates and use techniques like replication or message passing rather than shared memory.","**Be Aware of First-Touch** — Linux allocates memory on the node where it's first accessed ('first-touch policy'). Initialize data from the thread that will use it.","**Measure, Don't Assume** — NUMA behavior varies dramatically between systems. Always benchmark on target hardware and monitor production metrics."],"title":{"icon":"Target","text":"Core NUMA Design Principles","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**Principle 2: Avoid the Memory Allocation Anti-Pattern**\n\nA common mistake is to allocate all memory in a single thread (e.g., during initialization) and then distribute work across NUMA nodes. Because of first-touch allocation, all memory ends up on a single node, and most threads suffer remote access penalties.\n\n**The Right Approach:**\n\n1. Spawn worker threads, one per NUMA node\n2. Pin each worker to its NUMA node\n3. Have each worker allocate and initialize its own memory\n4. Only begin processing after all workers have their local memory\n\nThis ensures each thread's data is local. The initialization cost is minimal compared to the runtime savings."},"type":"text"},{"data":{"icon":"Lightbulb","title":"The NUMA Mental Model","content":"Think of a NUMA system as a collection of servers connected by a fast network, rather than a single unified machine. Each NUMA node has its own memory, and crossing node boundaries is like crossing a network boundary—possible, but with latency overhead. Design your software accordingly.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"numa-and-os","title":"NUMA and the Operating System","content":[{"data":{"content":"Operating systems play a critical role in managing NUMA systems. The OS must:\n\n1. **Discover and expose NUMA topology** to applications and administrators\n2. **Make intelligent allocation decisions** when applications don't specify preferences\n3. **Schedule processes** with awareness of where their memory lives\n4. **Balance memory utilization** across nodes while respecting locality\n\nModern operating systems (Linux, Windows, FreeBSD) all have NUMA support, though the depth and configurability varies."},"type":"text"},{"data":{"rows":[["NUMA-aware scheduler","✓ Full support","✓ Full support","Keep threads near their memory"],["Memory placement APIs","numactl, libnuma","NUMA API functions","Application-controlled placement"],["Automatic page migration","numad, AutoNUMA","Memory partition","Rebalance poorly placed pages"],["NUMA statistics","/proc/vmstat, numastat","Performance counters","Monitor local vs remote access"],["Huge page NUMA placement","✓ Supported","✓ Large pages","Reduce TLB misses with locality"]],"caption":"OS-Level NUMA Features","headers":["Feature","Linux","Windows","Purpose"]},"type":"table"},{"data":{"content":"**Linux's Approach: Default and Tunable**\n\nLinux uses several default policies that work well for many workloads:\n\n1. **First-Touch Allocation**: Memory is allocated on the node where it's first accessed\n2. **AffineScheduling**: The scheduler prefers to run threads where their memory is located\n3. **Memory Zones per Node**: Each NUMA node has its own zone lists for allocations\n4. **AutoNUMA/NUMA Balancing**: Kernel feature that detects misplaced pages and migrates them\n\nThese defaults are reasonable, but high-performance applications typically override them with explicit NUMA control."},"type":"text"},{"data":{"fileName":"linux-numa-tools.sh","languages":[{"code":"# View NUMA statistics\nnumastat\n# Output shows memory allocated per node and access patterns\n\n# Run a command bound to specific NUMA nodes\nnumactl --cpunodebind=0 --membind=0 ./my_application\n\n# Interleave memory across all nodes (for shared data structures)\nnumactl --interleave=all ./my_application\n\n# Check if NUMA balancing is enabled\ncat /proc/sys/kernel/numa_balancing\n# 1 = enabled, 0 = disabled\n\n# View per-process NUMA memory usage\ncat /proc//numa_maps\n\n# Monitor NUMA page faults and migrations\nwatch -n 1 'grep numa /proc/vmstat'","label":"Bash","value":"bash"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"When to Disable AutoNUMA","content":"AutoNUMA (numa_balancing) migrates pages to match thread locality automatically. While helpful for untuned applications, it can cause problems for applications that carefully place their memory. The migration itself consumes CPU and can cause latency spikes. Database vendors often recommend disabling AutoNUMA and using explicit NUMA placement instead.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-section","title":"Summary: Understanding NUMA","content":[{"data":{"content":"We've established the foundation of NUMA architecture. Let's consolidate the key concepts before moving forward:"},"type":"text"},{"data":{"type":"ordered","items":["**NUMA exists because SMP doesn't scale** — Shared bus architectures hit physical limits with increasing core counts.","**Memory access time is non-uniform** — Local memory access is 1.5-3x faster than remote memory access.","**NUMA topology is hierarchical** — Systems have multiple nodes with varying distances between them.","**Physical interconnects matter** — Intel UPI, AMD Infinity Fabric, and other technologies implement NUMA in hardware.","**Performance cliffs are real** — Poorly placed memory can degrade performance by 40-50% or more.","**Design for locality** — The core principle is keeping data near the processors that access it.","**Operating systems help, but aren't magic** — NUMA support is automated, but optimal performance requires application awareness."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nIn the next page, we'll dive deeper into **NUMA Nodes**—the fundamental unit of NUMA architecture. We'll explore how nodes are structured, what resources they contain, and how to query and work with nodes programmatically."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand why NUMA exists, how it differs from SMP, and the fundamental principles of memory locality that drive NUMA-aware system design. Next, we'll examine NUMA nodes in detail—the building blocks of the NUMA architecture.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_4425320f75c25ba7ca14f721ac559246","title":"NUMA Nodes","order":1,"content":null,"isLocked":true},{"id":"seed_e300ddbca357062c24263d3435b54953","title":"Local vs Remote Access","order":2,"content":null,"isLocked":true},{"id":"seed_46a4dc5eb129236a8c4bf502c748f5b0","title":"NUMA-Aware Allocation","order":3,"content":null,"isLocked":true},{"id":"seed_af4225a6ee6fd98be220105165d2f372","title":"Performance Optimization","order":4,"content":null,"isLocked":true}]}}