Intel 80486が発表されたのは1989年。バブル経済の最中、ベルリンの壁が崩壊した年のことだ。そのチップ向けに書かれた互換コードが、2026年までLinuxカーネルのビルド設定に条件分岐を残していた。
2026年6月14日にリリースされたLinux 7.1で、x86プロセッサのTime Stamp Counter（TSC）が起動時の必須要件になった。コミット「x86/cpu: Make CONFIG_X86_TSC unconditional」（111cbb45）は、Ingo Molnarが2025年4月にRFCとして提出した15本のパッチシリーズの一部で、2026年5月30日にtipツリーのx86/cpuブランチにマージされた。これにより、TSCを持たないx86 CPU向けにカーネルをビルドする選択肢そのものが消滅した。
TSCは、CPUのリセット以来経過したクロックサイクルを数える64ビットレジスタだ。1993年の初代Pentiumで導入され、RDTSC命令で読み出す。現代のIntel、AMDプロセッサにはすべて搭載されている。問題は、Pentium以前、すなわちi486や一部の互換CPUにはこのレジスタが存在しなかったこと、そしてPentium以降でもCyrix 6x86のようにTSCを持たない、あるいはRDTSCを不正命令として扱うクローンが存在したことだった。
Windowsが10年以上前に済ませていた判断
MicrosoftはTSCの扱いについて、Linuxよりずっと早く決断を下している。
Windows 2000とWindows XPで高解像度パフォーマンスカウンタAPI「QueryPerformanceCounter（QPC）」を導入した当初、TSCは信頼性が低く、Windowsはマザーボード上のHPETタイマーやACPI PMタイマーをQPCの基盤に使っていた。転換点はWindows 7（2009年）だ。定速率TSCを持つシステムでは、TSCをQPCの基盤として採用し始めた。Windows 8とWindows Server 2012（2012年）で、TSCはQPCの標準的な基盤になった。
この判断の背景には明確な性能差がある。Microsoftの公式ドキュメントによれば、TSCベースのQPC読み出しは数十から数百CPUサイクルで完了する。一方、マザーボード上のプラットフォームタイマーにフォールバックすると、読み出しコストは約0.8〜1.0マイクロ秒に跳ね上がる。TSCはCPUレジスタを直接読むだけなのでカーネル遷移を回避できるが、HPETやPMタイマーはメモリマップドI/O経由のアクセスが必要で、並行呼び出し時のスケーラビリティにも制約がある。
| 項目 | TSCベース | プラットフォームタイマー（HPET/ACPI PM） |
|---|---|---|
| 読み出しレイテンシ | 数十〜数百CPUサイクル | 約0.8〜1.0マイクロ秒 |
| アクセス方式 | CPUレジスタ直接読み出し（RDTSC/RDTSCP） | メモリマップドI/O |
| カーネル遷移 | 不要（ユーザーモードから直接読み出し可能） | 必要 |
| 並行アクセス | コアごとに独立、競合なし | 共有リソース、スケーラビリティに制約 |
| Windowsでの採用 | Windows 7（2009年）から段階的、Windows 8（2012年）で標準化 | Windows Vista/Server 2008でQPC基盤として使用 |
Linuxが同じ前提に立てなかった理由は、カーネルがi486時代まで遡るハードウェアをサポートし続けていたことにある。TSCの有無をビルド時に条件分岐し、TSCがない環境では別のタイマーに切り替えるコードが、30年以上にわたって維持されてきた。
Linusの一言が30年の互換コードに終止符を打った
2025年4月、Linus Torvaldsはカーネルメーリングリストでこう書いた。
「i486サポートはもう終わりにすべき時が来ていると感じる。この種の課題に開発努力を1秒でも費やす合理的な理由がゼロだ（I really get the feeling that it's time to leave i486 support behind. There's zero real reason for anybody to waste one second of development effort on this kind of issue.）」
この発言を受けて、x86サブシステムのメンテナであるIngo Molnarが15本のパッチシリーズ「x86: Remove support for TSC-less and CX8-less CPUs」を起草した。シリーズは5つの段階で構成される。
- M486/M486SX/ELANのCPUオプションとKconfig依存関係の削除
- TSC非搭載のM586（初代Pentiumの一部バリアント）サポート削除
- UMC、WinChip、RDC321XなどTSCなしクローンCPUのサポート削除
- CONFIG_X86_TSCを無条件化し、ビルド時のTSC関連条件分岐を簡素化
- CONFIG_X86_CX8（CMPXCHG8B命令）も無条件化し、関連するフォールバックコードを削除
このうち4番目が今回のコミットだ。変更自体は3ファイルで+1行/-3行と小さい。Kconfigのdepends on節からTSCを条件としていたCPUモデルの列挙（MWINCHIP3D、MCRUSOE、MEFFICEON、MCYRIXIII、MK7、MK6、MPENTIUM4など）を削除し、def_bool yだけで無条件に有効にする。実質的な変化はその前段にある。Linux 7.0（2026年4月12日リリース）でi486サポートが削除され、7.1の開発サイクルでTSCを持たない初期PentiumやクローンCPUのサポートも消えた。TSCが「常に存在する」とみなせる前提が整ったからこそ、この3行の変更が可能になった。
Molnarはコミットメッセージで「これはKconfigの接着剤を外すだけのもので、不要になった!X86_TSCコードの削除は別パッチで行う」と注記している。つまり、カーネルソース内にはまだTSCなしを前提としたデッドコードが残っており、今後のリリースで段階的に除去される。
TSCが「使えるタイマー」になるまでの20年
TSCの歴史は、そのままx86の電源管理との格闘の歴史でもある。
初代PentiumのTSCは、CPUの実際のクロック周波数に連動してカウントを進めた。CPUが省電力モードでクロックを下げればTSCの進みも遅くなり、ターボブーストで上げれば速くなる。壁時計としての時刻測定には使えない。さらにマルチコア時代が来ると、コア間でTSCの値が同期されない問題が加わった。
Intelが定速率TSC（Invariant TSC）を導入したのはCore 2時代（2006年頃）だ。CPUのPステートやCステートの遷移にかかわらず一定のレートでカウントが進む。AMDはFamily 10h（Barcelona/Phenom、2007年）から同等の機能を提供している。Linuxでは/proc/cpuinfoのconstant_tscフラグで確認できるこの特性が、TSCを信頼できる時刻源に変えた。
しかし、カーネルは定速率TSCがない古いCPUもサポートし続けなければならなかった。TSCの較正、信頼性の検出、問題がある場合のフォールバック。これらのコードが、TSCが普遍的に使える現代のCPUにとってもオーバーヘッドになっていた。
「Linux 7.0」という番号の意味
補足として、バージョン番号の経緯に触れておく。2026年2月8日、Linus Torvaldsは次のカーネルリリースを7.0として公開すると発表した。これは6.x系列のメジャーアップグレードではなく、従来の慣例に従えば6.20に相当するリリースだ。メジャー番号の繰り上がりは、Linusが「番号が大きくなりすぎた」と感じるたびに行う慣行的なもので、技術的な断絶があるわけではない。
ただし、7.0と7.1は結果としてx86のレガシーサポートにとって大きな区切りになった。7.0でi486サポートが削除され、7.1でTSCとCX8が必須になった。The Registerの報道によれば、Linux 7.1では14万行以上のコードが削除されており、さらなる削除が予定されている。
残るコードと、消えない問い
今回のコミットは、カーネルの「前提条件」を変えたにすぎない。TSCなしの環境を想定したフォールバックコード、CMPXCHG8Bをエミュレートするcmpxchg8b_emu.S、386時代の64ビット原子操作を再現するatomic64_386_32.Sといったファイルは、まだソースツリーに存在する。これらの削除は今後のリリースで進む見込みだ。
もう一つの問いは、この方針がどこまで進むかだ。Debianでは2025年10月に、Debian 14（forky）以降でx86-64-v2（SSE4.2、POPCNTなど、2008年のNehalem世代以降）を必須にする提案が議論されたが、結論は出ていない。FedoraでもQEMUがx86-64-v2を要求する変更をマージしたことで、ディストリビューション全体のベースラインをどうするかの議論が起きている。
カーネル自体は、x86-64（AMD64）モードでビルドする場合、すでにSSE2やFXSRなどを必須としている。TSCの必須化は、32ビットx86のレガシーを削る作業の一環であり、64ビット環境のユーザーには実質的な影響がない。影響を受けるのは、1990年代の組み込み機器や産業用コントローラで古いカーネルを動かしている、ごく少数のユーザーだ。Molnarのパッチシリーズにも「実際のユーザーには影響がないはずで、レガシーユーザーは古いカーネルを使い続ければよい」という注記がある。
30年以上にわたってカーネルが背負ってきた「TSCがないかもしれない」という条件分岐が、3行のコミットで消えた。技術的には小さな変更だが、x86 Linuxがどの時代のハードウェアを「現役」とみなすかという線引きが、1993年から2008年以降へと大きく動いたことを示している。
