Arm CPU での TSO メモリ モデルのサポート [LWN.net]

LWN加入者のメリット

主なメリットは、 LWNに加入する
は公開を続けるのに役立ちますが、それを超えて、購読者はすべてのサイト コンテンツに即座にアクセスし、多くの追加のサイト機能にアクセスできるようになります。今すぐご登録ください。

による ジョナサン・コーベット
2024 年 4 月 26 日

CPU レベルでは、メモリ モデルは、特にプロセッサがメモリ操作の順序を変更するために持つ自由度を記述します。低レベルのコードでメモリ モデルが考慮されていない場合、予期せぬ事態が起こる可能性があります。当然のことながら、CPU が異なれば提供されるメモリ モデルも異なるため、特定の種類の同時ソフトウェアの移植性が複雑になります。作業を容易にするために、一部の Arm CPU は x86 メモリ モデルをエミュレートする機能を提供していますが、その機能をカーネルで利用できるようにする取り組みが反対に遭っています。

CPU 設計者はパフォーマンスを向上させるためにあらゆる努力をします。メモリ アクセスに関しては、「すべて」には、操作のキャッシュ、順不同での実行、複数の操作を 1 つに結合するなどが含まれます。これらの最適化は、単独で実行されている単一の CPU には影響しませんが、メモリ操作が驚くべき順序で他の CPU に表示される可能性があります。システム内の別の場所で実行されている不注意なソフトウェアは、コードの読み取りから予想される順序とは異なる順序でメモリ操作を実行する可能性があります。 この記事 物事がどのようにうまくいかなくなるかについての 1 つの簡単なシナリオを説明します。 ロックレスアルゴリズムに関するこのシリーズ は、メモリの順序に関連する問題を回避するために使用できるいくつかのテクニックを詳細に示しています。

x86 アーキテクチャは、「トータル ストア オーダリング」(TSO) として知られるモデルを実装しています。これは、書き込み (ストア) が実行された順序ですべての CPU に認識されることを保証します。読み取りも並べ替えられませんが、読み取りと書き込みの相対的な順序は保証されません。 TSO アーキテクチャ用に作成されたコードでは、多くの場合、操作の特定の順序を強制するために必要となる高価なバリア命令の使用を省略できます。

代わりに、Arm メモリ モデルはより弱いため、CPU に操作をより自由に移動させることができます。この設計の利点は、実装が簡素化され、順序保証が必要ない状況 (ほとんどの場合) でパフォーマンスが向上する可能性があることです。欠点は、同時実行コードを正しく記述するにはもう少し注意が必要になる可能性があり、より厳密なメモリ モデル (TSO など) 用に記述されたコードは、Arm CPU で実行すると (おそらく微妙な) バグが発生する可能性があることです。

弱い Arm モデルが問題になることはほとんどありませんが、x86 プロセッサのエミュレーションという問題が発生する状況が 1 つあるようです。 x86 エミュレータが TSO メモリ モデルもエミュレートしない場合、同時実行コードは失敗する可能性が高くなりますが、メモリ バリアの挿入が必要な TSO をエミュレートすると、パフォーマンスが大幅に低下します。 Arm CPU の一部のユーザーが実行できるようにしたいと考えている同時実行 x86 コードの 1 つのタイプ (ゲーム) があるようです。奇妙なことに、これらのユーザーは、パフォーマンスも正しさも欠けている状態でオークの大群と対峙することを嫌います。

腕の TSO

偶然にも、一部の Arm CPU ベンダーはこの問題を理解しており、Hector Martin が次のように説明しています。 このパッチシリーズは、TSO メモリ モデルをプロセッサに実装しました。一部の NVIDIA および富士通 CPU は常に TSO で実行されます。 Apple の CPU は、実行時に有効にできるオプション機能としてこれを提供します。 Martin の目的は、この機能をユーザー空間に表示し、ユーザー空間で制御できるようにすることです。

このシリーズは、いくつかの新しいものを追加することから始まります prctl()

操作。 PR_GET_MEM_MODEL CPU によって実装された現在のメモリ モデルを返します。その値は次のいずれかになります
PR_SET_MEM_MODEL_DEFAULT または PR_SET_MEM_MODEL_TSO。の
PR_SET_MEM_MODEL 操作では、要求されたメモリ モデルの有効化が試行され、成功したかどうかを示す戻りコードが返されます。要求されたものよりも厳密なメモリ モデルを選択することができます。常時 TSO CPU の場合、TSO の要求は明らかに成功します。 Apple CPU の場合、TSO を要求すると、適切な CPU ビットが設定されます。 TSO をサポートしていない CPU 上で TSO を要求すると、予想どおり失敗します。

Martin は、コードは新しいものではないと指摘しています。このシリーズはしばらくの間、ダウンストリームのAsahi Linuxツリーで開発されており、数千のユーザーに出荷されています。興味深いことに、Zayd Qumsieh 氏は次のように投稿しました。 同様のパッチセット ただし、そのバージョンでは、Apple CPU 上の仮想マシンで実行される Linux 用の機能のみが実装されていました。

Apple CPU でより高速なゲームを楽しみにしている人々にとって残念なことに、どちらのパッチ セットもカーネル内の Arm アーキテクチャ コードの管理者には人気がありません。ウィル・ディーコン 表現された
彼の “強い反対同氏は、この機能はユーザー空間のコードの断片化を引き起こすと述べ、問題が解決すると思われる場合、開発者は TSO ビットを有効にするだけで、その結果、コードが他の Arm CPU 上でおそらく微妙な方法で失敗する可能性があると述べました。カタリン マリーナも同様です。 示された
彼は、この種の実装定義の機能を利用可能にするパッチをブロックすると述べました。

マーティン 答えた
断片化が問題になる可能性は低いと述べ、これらの非互換性にどのように対処できるかの一例として、一部のプロセッサ (Apple を含む) でサポートされているさまざまなページ サイズを指摘しました。同氏は、これまでのところ、TSO 機能をエミュレータ以外のものに使おうとした人はいないため、他のソフトウェアで悪用される可能性は低いと述べた。それを排除しても状況は改善しない、と彼は言う。

ここには実際的な議論があります。これは必要であり、拒否された場合でも絶対に下流に出荷され続けるため、断片化のリスクに大きな違いはありませんね。 Linux-on-Mac ユーザーの大多数は、アップストリームよりも早く新しい機能やハードウェアのサポートを得るために、当面はダウンストリーム カーネルを実行し続ける可能性があります。したがって、これをアップストリームで許可しないことは、これを悪用できるかどうかに比べて状況を大きく変えるわけではなく、より多くのパッチを永久に保持することを強制することで、私たちの生活を困難にするだけです。

ディーコンですが、 と主張した
このような機能がマージされれば、他のソフトウェアでも使用できるようになるでしょう。」そして私たちはそれをサポートすることになるでしょう」。

このパッチが受け入れられない場合は、代替案を検討する必要があります。 1 つは、Martin 氏が説明したように、ツリーの外に置いておき、そのハードウェア上で実際に実行されるディストリビューションに配布することです。ディストリビューションによる追加の長い歴史により、最終的には、消極的なメンテナーによるパッチの通過が容易になる場合があります。もう 1 つは、Apple CPU で TSO を無条件に有効にすることかもしれませんが、これには全体的なパフォーマンスの低下 (約 9%) が伴います。 マーティンによれば。もう一つの可能性は 言及された Marc Zyngier は、TSO を有効にして仮想マシンを起動し、カーネルを完全に意識させずに、その中で実行されているアプリケーションで TSO を利用できるようにすることを提案しました。

このような議論はすぐには終わらないようです。 Linux が長年にわたって際立った点は数多くありますが、その 1 つは、ユーザーがハードウェアを最大限に活用できる機能にあります。有用なハードウェア機能のサポートを拒否することは、その歴史に反することになります。ただし、この機能の悪用の可能性に関する懸念も、長年の経験に基づいています。これは、開発コミュニティが、必要な機能をサポート可能な方法で利用できるようにするソリューションを見つけることで、その長い歴史の別の部分を繰り返す必要があるケースです。