9月版　タイマにまつわるエトセトラ

小崎資広
2008/10/9

x86、「タイマを分かってないで賞」を受賞!?

　タイマ関係でもう1つ、話題を紹介しましょう。

　Larry Fingerは、「2.6.27で、僕の古いラップトップのTSC（Time Stamp Counter）が狂いだした」と報告しました。

　bisect（注6）の結果、2.6.27において、いままでx86_32とx86_64とで別々に実装されていたある処理のコードを1つにマージしたことが原因と分かりました。それが、TSCキャリブレーションという処理です。x86にはTSCのベースクロックを取得する方法がないため、（主にブート時に）簡易ベンチマークによりTSC速度を測定するものです。

　その後、さらなる調査により、コード自体にバグがあるのではないことが分かりました。Fingerの使っていた環境では、ACPIのPMタイマが規定の2倍のスピードで進む奇妙なハードウェアだったことが原因だったのです。

　いままでは、過剰チェックと思われていた個所によって、このような奇妙なハードウェア環境でも、PMタイマではなく、古きよきPIT（注7）による測定結果が選択されていたため、問題になっていませんでした。しかし、今回の共通コードへの移行時に、よりシンプルなx86_64コードをベースにしたことにより、PITではなくPMタイマの測定結果が選択されるようになってしまい、問題が顕在化したようです。

　PCにはさまざまなタイマハードウェアが搭載されている可能性があります。その中から一番精度のよいものを選ぶのが最善なのですが、中には実装が狂っている場合もあり、このときは精度が高いものが狂っていた、というわけです。

■古いヘンテコハードウェアとの戦いは続く

　さて、これで原因は分かったものの、どのように修正するかが議論になりました。

　まず、古いハードウェアではHPETは使用できず、PMタイマは信頼できないため、PITを使うのが最善の選択です。Linusは当初、32ビットでは常にPITを使うことを提案していました。しかし最近のハードウェアではPITが信頼できないことが分かったため、この提案もあまりいい手とはいえなくなりました。

　どういうことかというと、x86にはSMM（注8）と呼ばれる動作モードがあり、システムがOSを経由せずに、ファームウェアの省電力機能やレガシーデバイスエミュレーション機能を動かすために使われています。そしてシステムによっては、長時間にわたってSMMから復帰しないため、PIT割り込み処理が滞り、ベンチマーク上無視できないほどの誤差が生じてしまうのです（省電力機能が目玉機能となるラップトップ分野でこの問題は発生しやすいようです）。

　また、世の中には「狂ったハードウェア」がたくさんあるので、単純にCPU世代で判別しようとしても、うまくいきません。

　結局、32ビットの冗長なコードを復活させ、5回ずつベンチマーク測定を行い、その中からおかしな値は捨てるという“力業コード”で解決することになりました。

　これ以外にもx86のハードウェア依存コードでは「クリーンナップしたら、昔のヘンテコ・ハードのためにリグレッションが……」といった話がやたらと多いです、やれやれ。Thomas Gleixnerは、こうした時間系のトラブルにかなりうんざりしているようで「間違いなくx86が『タイマを分かってないで賞』大賞だね」と嘆いていました。

注6：git bisectというコマンドがあり、しばしば、どのコミットでリグレッションが発生したかを調査するのに使われます。 注7：PIT（Programmable Interval Timer）とは、PCならすべてのマシンに搭載されている由緒正しいタイマです。とはいえ30年近く前に設計されたため、精度が低い、ワンショットタイマ機能が使いも物にならないなどの問題点が指摘されています。 注8：SMM（System Management Mode）は、x86CPUには昔からモードとしては実装されていましたが、実際にはあまり使われていませんでした。しかし最近のPCでは、電力制御の都合上などでACPI BIOSが使っています。

-stableの進ちょく

　9月には、久しぶりに2.4系のアップデートがありました。またサミット前で慌ててリリースされた2.6.26.4に対しては、「ビルドできない」と苦情が寄せられ、急きょ2.6.26.5をリリースする羽目に。それに懲りたのか、サミット以降、-stableリリースはしばらく動きがない状態になっています。

■2.4.x:

• 2.4.36.7（9月7日）：Willy Tarreau
  ・sctp：intオーバーフローを防ぐためにチェックを追加（CVE-2008-2826）
  ・wan：sbni_ioctl()において権限チェックが抜けていた（CVE-2008-3525）
  ほか、13パッチ

■2.6.25.y:

• 2.6.25.17（9月8日）：Greg K-H
  ・/proc/sys/sunrpc/transportsのオーバーラン問題を修正
  ・nfsd：NFSv4 ACLのデコード処理のバッファオーバーラン問題を修正
  ・x86：壊れたBIOSが間違ったMTRRを設定することにより、トータルメモリが不当に小さくなってしまう問題を修正
  ほか、16パッチ

■2.6.26.y:

• 2.6.26.4（9月8日）：Greg K-H
  ・drivers/char/random.c：間違ったアサーションによりレース時にパニックしてしまう障害を修正
  ・/proc/sys/sunrpc/transportsのオーバーラン問題を修正
  ・ipsec：xfrm_state管理の中のデッドロックを修正
  ・PCI：pci_get_dev_by_id()のリファレンスカウンタリークを修正
  ・udp：カプセル化されたパケットのソケットロックをドロップした
  ・x86：壊れたBIOSが間違ったMTRRを設定することにより、トータルメモリが不当に小さくなってしまう問題を修正
  ・nfsd：NFSv4 ACLのデコード処理のバッファオーバーラン問題を修正
  ・rtc_time_to_tm：計算時の符号付き／符号なしの間違いを修正
  ・x86：Cyrix MediaGX（Geode）がブートしない問題を修正
  ・・sata_mv：（libataが混乱するので）2つのDMAコマンドを同時に発行しないようにした
  ほか、43パッチ

• 2.6.26.5（9月8日）：Greg K-H
  ・2.6.26.4がビルドできない問題を修正

（以上、敬称略）

2/2

Index Linux Kernel Watch　9月版 　タイマにまつわるエトセトラ

Page 1 　ある意味「予想どおり」のカーネルサミット 　カーネル時間管理の全面刷新なるか Page 2 　x86、「タイマを分かってないで賞」を受賞!? 　-stableの進ちょく

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）