3 ms·
Memory corruptions can impact very differently. A sample of decoded music getting corrupted leads to a small glitch, maybe even inaudible. An instruction in exe
by magicalhippo 3y ago
Memory corruptions can impact very differently. A sample of decoded music getting corrupted leads to a small glitch, maybe even inaudible. An instruction in executable code getting corrupted can leads to all sorts of havoc.
Since ECC is seemingly not getting mandatory, I've been wishing CPUs would support "soft-ECC". That is, the OS could mark certain pages as needing "soft-ECC", and the CPU would then store (at least) three copies of that page in RAM. When reading such pages back from RAM the CPU would read all physical copies and compare. If the majority agrees it can use that, otherwise raise an error.
This could then be used for executable pages and important configuration data which occupies relatively few pages, and where integrity matters a lot more than speed.
There's probably some good reasons why this is non-trivial to implement, I've forgotten most of what I learned about the virtual memory implementation in CPUs. But a man can dream...
- HideousKojima 3y agoThe triple reading/writing to memory along with the comparing would probably be a significant performance hit. You could just use a bit of extra memory for parity bits etc. instead
- magicalhippo 3y agoSure it would be a significant hit. But only for relatively few pages, and I imagine most of them would either stay cached or are very cold. Of course you could trade implementation complexity for speed as always. My main point was to have effective ECC without any additional support from motherboard and memory modules.
- menaerus 3y agoThe important detail to make your theory plausible, and without a huge performance impact and/or jittering, is how the kernel memory management system is going to decide what exactly is those "relatively few pages" on a server that runs a plentiful of processes, many of them including critical/heavy ones such as databases? One such example comes to my mind - transparent huge pages. And it didn't turn out to be quite successful. I imagine soft-ECC would be more plausible if it could be applied/enabled: 1. Per-process (e.g. whole application) 2. Or fine-grained per-allocation within a process/application I think both could be implemented through a (system) memory allocator by taking the advantage of page alignment LSBs and/or (non) addressable bits of the virtual memory. Those spare bits in memory can be used to store the encoding of ECC algorithm (Hamming, Reed-Solomon, or something more primitive but less robust). And then, depending on the ECC algo, one could substantially minimize the performance impact of encode/decode by using SIMD.
- magicalhippo 3y agoI imagined executable pages and pages explicitly marked by the application/kernel via VirtualProtect[1] or similar. Of course an application that marks GB of data this way could play havoc with other processes, so maybe some OS limits on how many non-executable pages a process can mark may be needed. And there certainly might be some further dragons I'm not considering. [1]: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualprotect https://learn.microsoft.com/en-us/windows/win32/api/memoryap...
- grog454 3y agoHow does the OS know which pages to mark?
- magicalhippo 3y agoAs I mentioned in my other reply[1], I imagined executable pages and those marked explicitly through code. This allows the kernel and applications to protect important variables and data structures. [1]: https://news.ycombinator.com/item?id=40297035 https://news.ycombinator.com/item?id=40297035
- smallpipe 3y agoThat relies on hardware support in the TLB. If you need TLB support for "please don't corrupt this page" you might as well get hardware with ECC in caches and RAMs
- magicalhippo 3y agoWhich relies on three components supporting ECC, not just one. But sure, ECC all around would be best. Btw, it was my understanding that CPU caches already use ECC?