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


小崎資広
2008/10/9

 linux-kernelメーリングリストかいわいで起きるイベントを毎月お伝えする、Linux Kernel Watch。2008年9月のカーネル関係の状況について見てみましょう。

ある意味「予想どおり」のカーネルサミット

 最近いきなり寒くなったので体調を崩している筆者です。皆さま、いかがお過ごしでしょうか。

 年に1度の大イベント、カーネルサミットが終わり、あちこちで速報が流れているようです。

 Alan CoxのLinux 3.0(注1)が否決されたほか、I/O周りをSSDに最適化しようという提案も否決(注2)、カーネルトレース機能(注3)もLinusの「オレ、イラネー」発言で否決と、予想どおりというか、あまり意外性のない結果になったようです。記事を書く立場としては、ネタを拾えなくて少し残念です。

 では、最近のLKMLで起きたトピックを追ってみましょう。どうぞ!

注1:「バージョンを3.0に上げて、それを機に不要なコードを捨てようぜ。ISAドライバなどのメンテされてないドライバとか、うざいよね」という提案。

注2:現在のSSDは、登場して間もないこともあってさまざまな欠点があり、ソフトウェア側で改善できる余地がたくさんあります。ですが、SSDのデバイス自体が猛烈な勢いで進化しており、近い将来、デバイス側で解決される確率が高い。そのため、いまのデバイスに最適化してもデッドコードを量産するだけになるのではないか、というのが理由のようです。Intelが「うちのSSDは、単に高速なHDDとして使えるよう作ったぜ」と豪語しているのも大きかったのかも。

注3:SystemTapやLTTngに代表される、カーネル内にフックを仕込んでカーネル内部状態をユーザー空間に通知する機能。パフォーマンスチューニングや障害解析に用いる。類似機能としてSolarisの「DTrace」がある。

カーネル時間管理の全面刷新なるか

 従来、カーネルの時間は「jiffies」と呼ばれる定期的なタイマ割り込みで管理されていました。この精度は、当時のPCのハードウェア性能の都合上、10ミリ秒(Hz=100のとき)から1ミリ秒(Hz=1000のとき)程度でした。

 最近販売されているPCでは、HPET(High Precision Event Timer)などの高精度タイマが一般的となってきました(HPETは10MHzの精度を持つと規定されており、CPUさえ追い付けば0.1μ秒単位の処理が可能です)。しかし下位互換性を確保するため、POSIX timerやnanosleep()などの一部のシステムコールでしか使用されていませんでした。

 そのため、システムコールの引数の仕様上はselectがμ秒、pselect()/ppoll()がナノ秒の精度を受け取るにもかかわらず、実際にはjiffies単位に切り上げた値で処理を行っています。この結果、例えばHz=1000のときは、最大9999μ秒の誤差が生じていました(注4)。

 ところが現実問題として、一般的なアプリケーションがnanosleep()などで寝る(=実行を一定時間停止する)機会は非常にまれです。ほとんどのケースでは、poll()、select()、epoll()などのイベント待ちシステムコールで寝ています。ほぼすべてのGUI Toolkitは、さまざまなイベントに対応するために、内部でselect()やpoll()を使ってイベントハンドリングをしているからです(注5)。

 ところが、コマンドラインのマルチメディアアプリケーションなどほとんど存在しません。よって、事実上、Linuxにおいてマルチメディアアプリケーションを作るのは非常に難しいという問題になっていました。

 Arjan van de Ven(おーい、fastbootはどうなった?)は、そういった状況を改善するために「select()、poll()、epoll()、pselect()、ppoll()などのイベント待ちシステムコールについても、高精度タイマ対応をすべきではないか」と問題提起しました。

■消費電力を増やさず精度を上げろ!

 ところが、意外なところに伏兵がありました。機能的にバグがなくても、高精度タイマの使用率が上がることそれ自体が問題で、それによりCPUの起床回数(=実行可能状態に戻る回数)が増え、消費電力が上がってしまうというのです。

 議論の末、タイムアウト値に「soft expire」と「hard expire」を設け、「soft expire以上、hard expire未満のどこかで発火すればよい」というカーネルタイマインターフェイスを新設し、発火時間が近いタイムアウト値を1つにまとめて処理することで消費電力を抑えようということになりました。

 残った問題は、このdelta値(hard expire−soft expire)をどうやって求めるかです。システムコールに引数を追加することはできません。そのような新システムコールを追加しても、ほとんどのアプリケーションは従来のシステムコールを使い続けるので意味がないからです。

 結局、「システムコールの引数のタイムアウト値の0.1%(niceされたプログラムの場合は0.5%)をdelta値として使う。ただし、この値がスレッドごとに決められた最小delta値を下回ったときは、スレッドの最小delta値を使う」という仕様になりました。この最小delta値は、prctlシステムコールのPR_GET_TIMERSLACK/PR_SET_TIMERSLACKにより取得/設定でき、デフォルトでは50μ秒になっています。

 これにより、消費電力をほとんど増やすことなく、イベント待ちシステムコールの精度を大幅に向上させることができ、このパッチはlinux-next入りとなりました。おそらく次のマージウィンドウでマージされると思います。

注4:実は、今回の修正中に見つかったバグで、selectの切り上げ処理が誤っていることが分かり、条件によっては切り上げではなく切り捨てになっていたことも判明しました(SUSv3などでround upを要求されている)。この件も今回修正されました。

注5:余談ですが、サーバ用途のソフトでは、複数のコネクションをさばくために、やっぱりepoll()などを使う羽目になります。

8月版へ
1/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カーネルの開発体制などについて伺った

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します


Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Linux & OSS 記事ランキング

本日 月間