Linux 7.4で『2バイト比較交換』に対応へ、専用命令のないCPUでも動作可能に

Linux 7.4に向け、2バイトの値を比較して書き換える「比較交換」を、専用の命令を持たないCPUでも利用できるようにするパッチが提案された。Bradley Morgan氏が作成した5本のパッチを、Paul E. McKenney氏が取り込み依頼としてまとめている。対象はSH、ARC、C-SKY、Xtensaの4つのアーキテクチャで、CPUごとの機能の違いを吸収し、カーネルの共通コードで2バイトの比較交換を利用できるようにする狙いだ。ただし、2バイトを直接書き込む命令がないという制約は解消されない。また、McKenney氏は10月20日、関連するサポート終了の議論について、対象はArmアーキテクチャ全体ではなく、特定の旧式システム「Acorn Risc PC」だと補足した。

4バイトの比較交換を使って2バイトを更新する

今回追加されるのは、cmpxchg_emu_u16()という関数だ。既存の1バイト用エミュレーションと同様に、4バイトの比較交換を利用して、より小さなデータ幅の操作に対応する。パッチの説明によると、対象の4アーキテクチャでは2バイトの比較交換に対応しておらず、この操作を使用するとコンパイル時やリンク時にエラーが発生する場合があった。今回の変更は、そうした不足を共通の関数で補うものだ。

比較交換とは、メモリ上の値をあらかじめ指定した期待値と比較し、一致した場合に限って新しい値に書き換える操作である。比較と更新を一体として実行するため、値を読み取ってから書き込むまでの間に別の処理が値を変更していても、その変更を見落として上書きすることを防げる。今回の関数は、更新対象の2バイトを含む4バイトの領域全体に対して比較交換を実行する仕組みになっている。

10月7日に投稿された実装では、まずREAD_ONCE()で4バイトの値を読み取り、対象となる2バイトが期待値と一致するかを確認する。一致しなければ、実際に読み取った値を返して処理を終了する。一致していれば、残りの2バイトを維持しながら、対象部分だけを新しい値に置き換えた4バイトのデータを用意する。そのうえで、元の4バイトの値との比較交換を試みる。

この仕組みでは、更新対象に隣接する2バイトも重要になる。別の処理が隣接部分を先に変更した場合、対象の2バイトが変わっていなくても、4バイト全体の比較交換は失敗する。関数は比較交換が返した値を使って処理をやり直すため、隣接部分の古いデータを誤って書き戻すことを防げる。また、実装には対象アドレスが2バイト境界に整列しているかを確認し、問題があれば警告する処理も含まれている。

関数の引数と戻り値にはunsigned longが使われているが、値の比較や代入ではu16に変換されるため、実際に操作するデータは16ビットのままだ。パッチの説明によると、この設計はアーキテクチャ側のマクロがデータサイズごとの処理を検査する際、ポインターに対する比較交換で型変換の警告が発生するのを避けるためだ。つまり、関数の引数や戻り値の型と、実際に比較・更新するデータの幅は区別されている。

比較交換に対応しても、直接書き込みの制約は残る

McKenney氏はパッチの取り込み依頼で、2バイトの比較交換を共通コードから利用できるようになっても、2バイトのアトミック操作を必要とするすべてのアルゴリズムが実装可能になるわけではないと説明している。Linuxが対応する一部のシステムには、2バイトの値を直接書き込む命令が存在しないためだ。比較交換と、値をそのままメモリに書き込む操作では、ハードウェアに求められる機能が異なる。4バイトの比較交換を使って2バイトの比較交換を再現できても、それによって2バイトの直接書き込み命令が追加されるわけではない。したがって、両方の操作を前提とするアルゴリズムでは、比較交換への対応だけで必要な条件が整ったとはいえない。

今回の変更を理解するうえでは、2バイトの比較交換、2バイトの直接書き込み、旧式システムのサポート削除を区別する必要がある。 それぞれ技術的な条件が異なるだけでなく、開発上の位置づけも違う。McKenney氏の取り込み依頼と10月20日の補足説明を整理すると、次のようになる。

確認事項	対象と技術的な条件	2026年10月20日時点の状況
2バイトの比較交換	SH、ARC、C-SKY、Xtensaで4バイトの比較交換を利用して実装	Linux 7.4向けに取り込みを依頼
2バイトの直接書き込み	一部の対応システムでは命令が存在しない	比較交換のエミュレーション後も制約が残る
Acorn Risc PCのサポート削除	Arm系の旧式システムを対象とする別の提案	削除は提案段階で、採用は未確定

この表は性能を比較したものではなく、それぞれの技術的な制約と開発状況を整理したものだ。今回のエミュレーションはSH、ARC、C-SKY、Xtensaの4アーキテクチャを対象としている一方、サポート削除の議論はArm系の個別システムに関するものである。両者は関連する技術的な制約を抱えているものの、直接同じ変更を指しているわけではない。比較交換の機能追加を理由に、特定のアーキテクチャ全体のサポートが終了すると解釈するのは誤りだ。

サポート終了の議論で名前が挙がったAcorn Risc PC

McKenney氏は10月20日の返信で、取り込み依頼に記したサポート終了に関する説明について、重要なのは「システム」という言葉であり、「アーキテクチャ」ではないと明確にした。具体的に指していたのは、Arnd Bergmann氏が削除を提案したAcorn Risc PCである。Armという命令体系全体のサポートを終了する話ではなく、古い特定のコンピューターシステムへの対応を今後も維持するかという問題だ。

Bergmann氏が9月8日に提出した削除提案には、比較交換のパッチだけでは分からない技術的な事情が記されている。Acorn Risc PCは1994年にARM610プロセッサを搭載して登場し、後にはStrongARMへの換装にも対応した。しかし、同氏によると、このシステムのCPUバスは16ビット幅のデータ転送に対応しておらず、カーネルをビルドする際には-march=armv3を指定する必要があるという。CPUを新しいものに交換できても、システム側のバスが扱えるデータ転送幅まで変わるわけではない。

さらに、-march=armv3オプションはGCC 9で廃止されており、Acorn Risc PCのサポートを維持するには、古いGCC 8に依存し続けなければならないという問題もある。これは、ハードウェアの命令不足をソフトウェアで補うだけでは解決できない制約だ。古いシステムへの対応を続けるには、カーネルのコードだけでなく、ビルドに必要なコンパイラや開発環境も維持する必要がある。こうした保守負担が、サポート削除を検討する理由の一つになっている。

ただし、削除が提案されたことと、実際に削除が決まったことは別である。McKenney氏は10月20日の補足で、この提案にはかなりの反対意見があったと記憶していると述べた。また、開発中の変更を集約する統合ツリー「linux-next」でも、まだ削除パッチを確認していないという。そのため、提案が近いうちに取り込まれるかどうかは分からないとしており、現時点でAcorn Risc PCのサポート終了時期が確定したわけではない。

共通コードの移植性改善と旧式システムの保守は別の課題

今回のパッチによって2バイトの比較交換が共通コードから利用できるようになれば、カーネル開発者はCPUごとの命令の違いを意識せずに、この操作を使いやすくなる。すでに1バイトの比較交換で採用されているエミュレーションを2バイトにも拡張することで、専用の命令を持たないアーキテクチャでも同じ操作を扱えるようになる。今回の変更の主な意義は、カーネルの共通コードが利用できる機能を増やし、異なるアーキテクチャ間での移植性を改善する点にある。

一方、エミュレーションでは4バイト単位の比較交換と、必要に応じた再試行が発生する。そのため、今回の変更によって処理が高速化したり、メモリ使用量が減ったりすると判断することはできない。取り込み依頼にも、性能面の効果を示すベンチマーク結果は掲載されていない。利用者が体感する性能よりも、まずはカーネルの共通コードで利用できる操作の範囲が広がることに意味がある。

パッチの採用状況についても、今後の確認が必要だ。McKenney氏は10月20日の別の返信で、Linus Torvalds氏がまだ今回の変更を取り込んでいないと説明している。Linux 7.4に向けた比較交換のパッチと、Acorn Risc PCのサポート削除案は、それぞれ独立した変更として採用状況を追う必要がある。また、比較交換のエミュレーションが取り込まれたとしても、それだけですべてのアトミック操作に対応できるわけではない。今後、共通コードで新たなアルゴリズムを採用する際には、比較交換だけでなく、通常の書き込みを含めて必要な操作が各アーキテクチャで利用可能かを確認する必要がある。