the row buffer

Back to the library reading room: the row buffer is that single open desk. You cannot read a book straight off the shelf — first you carry a whole shelf-worth onto the desk (slow), and then any page on the desk is instantly available (fast). If your next request happens to be another page from the book already on the desk, you save the whole fetch. If it is a different book, you must clear the desk and fetch again. The row buffer is exactly this fast, working copy of one DRAM row.

Concretely, when a bank's row is activated, every cell in that row dumps its tiny charge onto a strip of sense amplifiers, which detect each bit and latch the whole row — thousands of bits, often 1 to 8 KiB — into the row buffer. From there, a column access (CAS) reads or writes specific bytes very quickly. A request that finds its data already in the open row is a row-buffer hit (cheap, just a CAS). A request to a different row of the same bank is a row-buffer miss or conflict: the current row must be precharged (written back and the bitlines reset) and the new row activated before the CAS — much slower.

Why it matters: the row buffer is the DRAM-level version of locality. Because activating a row drags in kilobytes at once, accessing nearby addresses (the next bytes in the same row) is far cheaper than jumping to a scattered new row each time. This is one more reason spatial locality pays off all the way down to the chips. Memory controllers reorder requests to maximize row-buffer hits, and they choose whether to leave rows open (good for streaming) or close them eagerly (good for random access).