用于没有ECC的平台的软件存储器位翻转检测

时间:2014-05-11 00:02:01

标签: memory linux-kernel error-detection

大多数可用的桌面(廉价)x86平台现在仍然没有ECC内存支持(Error Checking & Correction)。但内存位翻转错误率仍在增长(not the best SO threadLarge scale CERN 2007 study "Data integrity":&#34; 内存模块的误码率为10 -12 ......观察到的错误率比预期的低4个数量&#34 ;; 2009年Google的"DRAM Errors in the Wild: A Large-Scale Field Study")。对于具有数据密集负载(8 GB / s读数)的当前硬件,这意味着每分钟可以发生单位翻转(来自CERN07的10 -12 供应商BER)或两天一次(10 < sup> -16 来自CERN07的BER)。 Google09表示每Mbit可以有多达25000-75000个一位FIT(每十亿小时的故障时间),相当于8GB内存每小时1-5位错误(&#34; 均值可纠正的错误率为每年每GB 2000-6000 &#34;)。

所以,我想知道,是否可以在系统范围内添加某种软件错误检测(检查用户和内核内存)。例如,为Linux内核和/或系统编译器创建一个补丁,为每个内存页面添加一些校验和,并尝试通过定期重新计算校验和来检测静默内存损坏(bit-flips)?

例如,我们可以看到对内存的所有写入(来自用户和内核空间),以区分内存位翻转中的预期内存更改吗?或者我们能以某种方式用一些帮助来检测所有代码吗?

据我所知,任何类型的软件内存ECC都可能会耗费大量性能并且无法捕获所有错误,但我认为在它们稍后重用之前至少检测一些内存位翻转会很有用。计算或存储到硬盘。

我也明白,更好的内存bitflip数据保护方法是切换到ECC硬件,但大多数PC仍有非ECC。

2 个答案:

答案 0 :(得分:3)

事实上,与“软件ECC对策”相比,ECC便宜得多。您可以轻松地检测他们是否有ECC模块并在他们没有时抱怨(或打印警告)。

http://www.cyberciti.biz/faq/ecc-memory-modules/

  

例如,我们可以看到对内存的所有写入(来自用户和内核空间),以区分内存位翻转中的预期内存更改吗?或者我们能以某种方式用一些帮助来检测所有代码吗?

呃,你永远不会“看到”公交车上的位翻转。它们实际上是由粒子击中RAM引起的,有点翻转。只有很久以后你才会注意到你读出了与你写的不同的东西。要仅通过总线检测到这一点,你需要一份所有你的RAM的副本(即创建一个影子副本在您的真实RAM中,因此您可以验证每次读取返回写入该位置的内容。)

  

尝试通过定期重新计算校验和来检测静默内存损坏(bit-flips)?

Redis家伙对用于测试RAM问题的算法进行了很好的描述。 http://antirez.com/news/43但这确实在寻找RAM错误,而不是随机的位翻转。

如果“重新计算校验和”仅在您不写入内存时有效。这可能“足够好”但你需要弄清楚哪些页面没有被写入。

要捕获100%的错误,必须通过计算该内存块的校验和,然后将其与记录的校验和进行比较(以确保块在RAM中没有降级)来预先进行每次写入。只有这样才能安全地进行写入然后更新校验和。你可以想象,这种表现将会很糟糕(至少要慢100倍)。

  

据我所知,任何类型的软件内存ECC都可能会耗费大量性能并且无法捕获所有错误,但我认为在它们稍后重用之前至少检测一些内存位翻转会很有用。计算或存储到硬盘。

嗯,有一种简单的方法来检测100%的错误,性能为50%:只需一次在2个盒子上运行计算(或者在两个不同的时间在一个盒子上运行,也许用RAM测试如果你是偏执狂之间。)如果结果不同,你已经检测到错误。

另见:

https://www.linuxquestions.org/questions/linux-hardware-18/how-to-detect-ecc-memory-errors-under-linux-886011/

答案 1 :(得分:0)

问题的答案是肯定的,并且证据就是评论中发布的软件SoftECC

请注意,SoftECC是一个内核级解决方案。如果使用用户登陆应用程序,它将是冗余的第三阶段,这似乎没有必要。