入手可能なほとんどのデスクトップ (安価な) x86 プラットフォームは、現在も ECC メモリのサポートを行っていません (エラー チェックと修正)。しかし、メモリ ビット フリップ エラーの割合は依然として増加しています (最適な SO スレッドではありません。大規模な CERN 2007 調査「データの整合性」 : 「メモリ モジュールのビット エラー率 10 -12 ... 観察されたエラー率は 4 桁です。予想よりも低い大きさの "; 2009 Google の"DRAM Errors in the Wild: A Large-Scale Field Study" )。データ集約型の負荷 (8 GB/秒の読み取り) を伴う現在のハードウェアの場合、これは、1 分ごと ( CERN07 からの10 -12ベンダー BER) または 2 日に 1 回 (10 -16CERN07 からの BER)。Google09 によると、Mbit あたり最大 25000 ～ 75000 の 1 ビット FIT (10 億時間あたりの時間の失敗) が存在する可能性があり、これは 8 GB の RAM で 1 時間あたり 1 ～ 5 ビット エラーに相当します (「2000 の修正可能なエラー率を意味します。年間 1 GB あたり 6000 ")。
それで、私が知りたいのは、システム全体の方法である種のソフトウェアエラー検出を追加することは可能ですか（ユーザーメモリとカーネルメモリの両方を確認してください）。たとえば、Linux カーネルおよび/またはシステム コンパイラ用のパッチを作成して、すべてのメモリ ページのチェックサムを追加し、定期的にチェックサムを再計算してサイレント メモリ破損 (ビット フリップ) を検出しようとしますか?
たとえば、意図したメモリ変更とメモリ内ビット フリップを区別するために、(ユーザー空間とカーネル空間の両方からの) メモリへのすべての書き込みを確認できますか? または、ヘルパーを使用してすべてのコードをインストルメント化できますか?
どのような種類のソフトウェア メモリ ECC もパフォーマンスに多大なコストがかかる可能性があり、すべてのエラーをキャッチするわけではないことは理解していますが、少なくともいくつかのメモリ ビット フリップを早い段階で検出すると、後の計算で再利用したり保存したりする前に役立つと思います。ハードドライブへ。
また、メモリのビットフリップからデータを保護するためのより良い方法は、ECC ハードウェアに切り替えることだと理解していますが、ほとんどの PC はまだ非 ECC です。