Dynamic RAM is organized into banks, rows, and columns. A memory request does not simply point at a byte and receive it at a fixed cost. Inside each bank, the device first brings an entire row into sense amplifiers that also act as a row buffer. Column commands then select data from that active row.
This organization creates a practical timing difference between accesses that stay on the active row and accesses that require a different row.
Activation Opens a Row
A DRAM cell stores a small electrical charge. Reading a row connects many cells to bitlines, and sense amplifiers detect and restore their values. The ACTIVATE command performs this operation for a selected row in a bank.
After activation, the row remains represented in the bank’s sense amplifiers. Read and write commands can then address columns within it. The bank does not need another activation for every column request while that row stays active.
This state is often described as an open row. It is local to a bank: separate banks can have different active rows at the same time.
Row Hits Avoid Extra Bank Commands
A request that targets the row already active in its bank is a row hit. The controller can issue the appropriate column command once timing constraints permit.
A request to another row in the same bank needs more work. The current row must be closed with PRECHARGE, which prepares the bitlines for another activation. The controller then activates the target row before issuing its column command.
Those extra operations add delay and consume command bandwidth. They also affect scheduling because DRAM timing rules impose minimum gaps between particular commands.
The result is not a universal latency number. Memory generation, transfer rate, timing parameters, controller policy, bank state, refresh activity, and contention all contribute to observed access time.
Address Mapping Shapes Row Locality
The memory controller maps physical addresses onto channels, ranks, banks, rows, and columns. The mapping determines which address patterns land in the same row and which patterns spread across banks.
Sequential traffic often produces useful row locality because adjacent cache lines can map to columns in one row. A controller may serve several requests from that row before closing it.
Random traffic can produce more row conflicts, especially when requests repeatedly target different rows in the same bank. More banks can provide parallelism, but bank parallelism and row locality are separate properties. A workload can use many banks while still causing frequent row changes within each bank.
Exact mappings are platform-specific and may include address hashing or interleaving. Software therefore cannot assume that a simple physical-address boundary always matches a DRAM row boundary.
Open-Page and Close-Page Policies Trade Different Costs
A controller can leave a row open after a request in case another request targets it. This open-page approach can reward locality with more row hits.
It can instead precharge sooner. A close-page approach gives up some chance of a future hit but may reduce the penalty when the next request targets another row.
Modern controllers can use adaptive policies rather than one fixed rule. They may consider queued requests, recent access patterns, fairness, power goals, and timing constraints when deciding which command to issue next.
Reordering also matters. If several queued requests target the active row, serving them together can improve throughput. Excessive preference for row hits, however, can delay requests aimed at other rows, so schedulers commonly balance locality against fairness and age.
Row Buffers Are Not CPU Caches
A row buffer can resemble a cache at a glance because recently activated data is available at lower command cost. The mechanism and role are different.
A CPU cache stores selected copies of memory data and can retain many cache lines according to its placement and replacement rules. A DRAM bank’s row buffer is part of the sensing path for the currently activated row. Activating another row in that bank replaces the previous row-buffer contents as part of normal DRAM operation.
A row hit therefore does not mean the processor found data in a conventional cache. It means the target row is already active inside the relevant DRAM bank.
Access Pattern Changes Command Work
Two workloads with similar byte counts can place different pressure on DRAM. One may repeatedly access columns from active rows, while another may force frequent precharge and activation cycles.
That difference can affect latency, effective bandwidth, energy use, and interference between concurrent request streams. It also helps explain the value of memory-controller scheduling: the order of queued requests can change the amount of row switching even when the requests themselves stay identical.
The key state is simple. Each DRAM bank can keep an activated row in its row buffer. Requests to that row reuse the active state; requests to another row require the bank to close the current row and activate the next one.