3 ms·

Wear levelling on RAM isn't in use today to my knowledge, but I don't think it is technically impossible. You would probably go for some approach where most me

Wear levelling on RAM isn't in use today to my knowledge, but I don't think it is technically impossible. You would probably go for some approach where most memory addresses are direct-mapped, and then the few that have been written most are redirected to new addresses. The reading of the direct-mapped addresses would be super fast, since you can do the read in parallel with the lookup in the remapping table (just to check that this is a direct-mapped address). Reads of non-direct mapped addresses might take a couple of extra cycles, but that doesn't matter because they are very rare. To do any of that, CPU memory controllers need to be able to handle per-request variable-latency RAM, which to my knowledge today they do not, although it would not be a big redesign to add.

ahoka 3y ago
Wear leveling RAM would be trivial with any MMU from the last 40 years. You can just fault on the write and do your wear leveling in the fault handler. This is how virtual memory already works.
- londons_explore 3y ago
  Indeed, and this is how "badram" on Linux works.
Tuna-Fish 3y ago
No, you would keep a write counter for every (4kB) DRAM page, and have the OS move the virtual page to new physical one if the write count of a page grows much higher than the average.
- vlovich123 3y ago
  That assumes you still have DRAM. Since this is faster and higher capacity than RAM, it’s potentially viable as a RAM replacement. In that case, you wouldn’t have anywhere to store the counters (but presumably in that case you wouldn’t need to either). I’m not sure you’d need to have a write counter when this replaced RAM though even if this didn’t have the same write endurance. For storage nodes, there’s no value in RAM outlasting storage. And this already has better write endurance than NAND. So on a storage node, you could easily imagine using this as RAM as the number of erases is going to be dominated by storage activity rather than ancillary memory writes managing the storage.

ahoka 3y ago

Wear leveling RAM would be trivial with any MMU from the last 40 years. You can just fault on the write and do your wear leveling in the fault handler. This is how virtual memory already works.

londons_explore 3y ago
Indeed, and this is how "badram" on Linux works.

Tuna-Fish 3y ago

No, you would keep a write counter for every (4kB) DRAM page, and have the OS move the virtual page to new physical one if the write count of a page grows much higher than the average.

vlovich123 3y ago
That assumes you still have DRAM. Since this is faster and higher capacity than RAM, it’s potentially viable as a RAM replacement. In that case, you wouldn’t have anywhere to store the counters (but presumably in that case you wouldn’t need to either). I’m not sure you’d need to have a write counter when this replaced RAM though even if this didn’t have the same write endurance. For storage nodes, there’s no value in RAM outlasting storage. And this already has better write endurance than NAND. So on a storage node, you could easily imagine using this as RAM as the number of erases is going to be dominated by storage activity rather than ancillary memory writes managing the storage.