the memory controller
Picture an air-traffic controller at a busy airport. Planes (memory requests) arrive in a jumble, runways and gates (banks and channels) are limited, and some operations take longer than others. The controller does not just serve planes first-come-first-served; it sequences them cleverly — sending one to an open gate while another is still taxiing — to keep everything moving and avoid collisions. The memory controller does exactly this for DRAM: it is the hardware that translates the CPU's memory requests into the precise low-level commands DRAM needs, in a smart order.
Concretely, the memory controller (today built right into the CPU) sits between the last-level cache and the DRAM. It takes addresses, maps them to channel/rank/bank/row/column, and issues the exact DRAM commands — ACTIVATE a row, READ or WRITE a column, PRECHARGE to close a row — while honoring every timing constraint (tRCD, CL, tRAS, refresh intervals, and more). Crucially it reorders and schedules requests: it tries to batch accesses to the same open row (row-buffer hits), spread accesses across banks and channels for parallelism, and interleave refreshes, all to maximize useful bandwidth and minimize stalls.
Why it matters: the memory controller is where the abstract memory request meets the messy physics of DRAM, and its scheduling quality has a large, real effect on performance. Good scheduling can turn a stream of would-be row conflicts into cheap hits; poor scheduling wastes bandwidth. It is also where address interleaving is decided — how consecutive addresses are scattered across banks and channels so that ordinary access patterns naturally exploit parallelism. In short, it is the brain that hides as much of DRAM's latency as physics allows.
Four pending reads target rows already open in banks 0, 1, 2, 3. The controller fires them at all four banks in overlap rather than serially — turning what could be four full row activations into four parallel, mostly-hit accesses.
Smart reordering across banks and channels is how the controller hides DRAM latency.
The controller hides latency; it cannot abolish it. With requests reordered for throughput, a single latency-critical access can still be delayed behind a batch — scheduling optimizes the average, sometimes at the tail's expense.