問題タブ [rcu]

Linux カーネルのコア RCU API は、カーネル内のすべてのクライアントに適用されます。つまり、rcu でサポートされたデータにアクセスするすべてのリーダー (まったく関係のないデータ構造にアクセスしている場合でも) は同等に扱われます。また、synchronize_rcu() などの呼び出しは、内部でまったく関係のないデータ構造にアクセスしている場合でも、すべてのリーダーを待機する必要があります。

Linux カーネルがデータ オブジェクトごとの RCU のサポートを追加しなかったのはなぜですか? ここで何か不足していますか？現在の RCU API の意味するところは、カーネルに多数のクライアントがある場合、それらがグローバル ビューを共有するため、RCU の全体的なパフォーマンスが低下する可能性があるということです。

次の抜粋は、Web サイトhttps://lwn.net/Articles/262464/からの抜粋であり、共有データ構造 (作成された RCU 用) の読み取りの不一致を扱っています。

このコード フラグメントは、誤った順序付けの影響を受けないように見えるかもしれませんが、残念ながら、DEC Alpha CPU [PDF] と値推測コンパイラの最適化により、信じられないかもしれませんが、p->a、p->b、および p- の値が生じる可能性があります。 >c は p の値の前にフェッチされます! これはおそらく、コンパイラーが p の値を推測し、p->a、p->b、および p->c をフェッチし、次に p の実際の値をフェッチする、値推測コンパイラーの最適化の場合に最も簡単に確認できますその推測が正しかったかどうかを確認するために。この種の最適化は非常にアグレッシブで、おそらくめちゃくちゃですが、実際にはプロファイル駆動型の最適化のコンテキストで発生します。

上記のコードが、へのアクセスで誤った (*) 値を生成することを意図しているのかどうかは不明ですp->a。書かれた（ソース内の）順序」は、まったく、当然のことながら、私にとっては問題ありません。

最初の解釈が正しければ、この種の動作を許容するシステム (コンパイラ) が壊れていると考えます。私の質問は、普及しているアーキテクチャ (アルファ) が既に消滅している可能性がある場合でも、これがまだ存在するかどうかです。

(*)p->aある記録とp->b別の記録、またはもっと悪いものに由来するという意味での誤った値

PS: チェックはしていませんが、gp変数が正しく装飾されていると想定していますatomic。