Could someone with hardware knowledge explain why it is necessary to read the entire row each time?
nba16235
@MangoSister. On the one hand, according to what the professor mentioned in the class, the row buffer will precharge itself and detect which row is activated, then transfer that row to the row buffer. Notice that the column selection happens after the row transfer, which means during the row selection stage the memory has no idea which column should be returned to the bus and thus needs the whole row. On the other hand, I feel like this is about improving the granularity of data transfer since we'd like to exploit the locality of memory.
Above is just my understanding. Correct me if I made a mistake.
bpr
@MangoSister, a DRAM cell is just a capacitor. When it is read, the capacitors discharge the stored charge, and that signal is run through sense amplifiers, etc to determine the values and place them in the row buffer.
@nba16235, you are right that there is locality here. If the next request to this bank accesses the same row, then the DRAM array can skip steps 1&2 and directly do the column selection and data transfer. In effect, the row buffer is a single entry cache. Should the access be to a different row, then the row must be written back (which takes time). Note, this is actually a design decision, depending on the workload, the DRAM may perform better by not saving the row in the row buffer and writing it back after the data transfer.
ferozenaina
@bpr - If a DRAM cell is a real capacitor, wouldn't it eventually lose charge if it isn't read (activated) or written to? Wouldn't the stored voltage value of '1' eventually decay and cross into the boundary voltage of value '0'?
How is this decay/data loss prevented?
bpr
@ferozenaina, this is a known problem. Therefore, DRAM has a refresh operation where it reads and writes the row back.
BBB
Memory cells losing their charges has also been exploited by the rowhammer attack. Basically, memory cells can lose their charge more quickly when nearby cells are precharged/refreshed. By continuously causing a single row of DRAM to precharge and refresh, an attacker can corrupt nearby memory cells if the memory controller does not refresh them often enough. This is particularly scary since the attacker does not need write permissions to the hammered row. The problem has only appeared in the last five years as a result of scaling, smaller memory cells are more vulnerable.
acortes
In case anyone is an interested as I was on how to prevent rowhammer attacks: doing some researched showed there there are a few solutions. One is to simply increase the rate of refreshing the row but that causes performance impact and more power consumption (bad). A better solution is to have a counter for the number of times a row is accessed and above a threshold refresh its neighbors, this works but is a bit complicated. Another good solution is to randomly refresh neighboring rows when accessing a row. The last two solutions have been shown to decrease the probability of the attack working and have little performance impact!
Could someone with hardware knowledge explain why it is necessary to read the entire row each time?
@MangoSister. On the one hand, according to what the professor mentioned in the class, the row buffer will precharge itself and detect which row is activated, then transfer that row to the row buffer. Notice that the column selection happens after the row transfer, which means during the row selection stage the memory has no idea which column should be returned to the bus and thus needs the whole row. On the other hand, I feel like this is about improving the granularity of data transfer since we'd like to exploit the locality of memory.
Above is just my understanding. Correct me if I made a mistake.
@MangoSister, a DRAM cell is just a capacitor. When it is read, the capacitors discharge the stored charge, and that signal is run through sense amplifiers, etc to determine the values and place them in the row buffer.
@nba16235, you are right that there is locality here. If the next request to this bank accesses the same row, then the DRAM array can skip steps 1&2 and directly do the column selection and data transfer. In effect, the row buffer is a single entry cache. Should the access be to a different row, then the row must be written back (which takes time). Note, this is actually a design decision, depending on the workload, the DRAM may perform better by not saving the row in the row buffer and writing it back after the data transfer.
@bpr - If a DRAM cell is a real capacitor, wouldn't it eventually lose charge if it isn't read (activated) or written to? Wouldn't the stored voltage value of '1' eventually decay and cross into the boundary voltage of value '0'?
How is this decay/data loss prevented?
@ferozenaina, this is a known problem. Therefore, DRAM has a refresh operation where it reads and writes the row back.
Memory cells losing their charges has also been exploited by the rowhammer attack. Basically, memory cells can lose their charge more quickly when nearby cells are precharged/refreshed. By continuously causing a single row of DRAM to precharge and refresh, an attacker can corrupt nearby memory cells if the memory controller does not refresh them often enough. This is particularly scary since the attacker does not need write permissions to the hammered row. The problem has only appeared in the last five years as a result of scaling, smaller memory cells are more vulnerable.
In case anyone is an interested as I was on how to prevent rowhammer attacks: doing some researched showed there there are a few solutions. One is to simply increase the rate of refreshing the row but that causes performance impact and more power consumption (bad). A better solution is to have a counter for the number of times a row is accessed and above a threshold refresh its neighbors, this works but is a bit complicated. Another good solution is to randomly refresh neighboring rows when accessing a row. The last two solutions have been shown to decrease the probability of the attack working and have little performance impact!