スケジューラとアルゴリズム

動画を書き出している間、マウスカーソルまで飛ぶ

エンコードを走らせたまま別の作業をしようとすると、クリックしてから反応が返るまで一拍空くことがあります。CPU 使用率は 100 パーセントで、機械はさぼっていません。それでも体感は最悪です。

コアの前には常に何十というプロセスが並んでいて、次に誰を座らせるかを決めている担当がいます。それがスケジューラです。エンコードは計算をひたすら回すので、順番が来るたびに割り当てられた時間を使い切ります。一方マウスの処理は、動いた瞬間にほんの少し走れればいい。この 2 つを同じ基準で並ばせると、後者が割を食います。

「早く終わらせる」と「すぐ反応する」は同時に立たない

行列の裁き方には昔からいくつかの型があり、それぞれ捨てているものが違います。

• 到着した順に最後まで走らせる方式は、実装が単純です。ただし先頭に長いジョブが来ると、後ろ全員がそれを見送ることになります
• 短く終わるものから先に処理すると、平均の待ち時間はいちばん小さくなります。代わりに長いジョブは、短いものが来続ける限り永遠に順番が回りません
• 全員に同じ長さの持ち時間を配って順ぐりに回すと、誰も飢えません。ただし持ち時間を短くするほど反応は良くなり、入れ替えの回数が増えてスループットは落ちます
• 重要度で順位を付ける方式は、リアルタイム性が要る用途では必須です。代わりに低い側が延々と待たされます

どれかが正解ということはなく、何を優先する機械なのかで選び方が変わります。手元のパソコンとバッチ処理専用のサーバーでは、望ましい設定が逆になります。

1 人あたりの持ち時間をどれだけにするかも、同じ天秤の上にあります。短くすれば順番はすぐ回ってきて反応が良くなりますが、その分だけ入れ替えの回数が増え、正味の仕事に使える時間が削られます。長くすれば効率は上がりますが、待たされる側の体感が悪くなります。手元の機械では数ミリ秒程度が既定で、バッチ処理に振り切ったサーバーでは長めに寄せる設定もよく見かけます。

Linux は「いちばん使っていない人」を選ぶ

Linux が長く採ってきた考え方は、これまでに使った時間がいちばん少ないプロセスを次に走らせる、というものです。走った分だけ持ち時間が加算されていき、加算値が最小の相手が次に呼ばれます。誰かが CPU を独占すると加算値が伸びるので、自動的に順番が回ってきません。

nice の値は、この加算の進み方を変えるつまみです。値を下げると加算がゆっくり進むので順番が回りやすくなり、上げると譲る側になります。

nice -n 10 ./video-encode &     # 譲る側に回す

エンコードを譲る側に回すだけで、マウスの反応はかなり戻ります。逆に上げすぎ、つまり最優先に振り切ると、OS 自身の管理タスクまで待たされて全体が不安定になります。

スケジューラはさらに、最近ずっと入出力を待っているプロセスを対話的だと見なして優先します。キーを打ったらすぐ文字が出る、という体感はこの判断が作っています。動画のエンコードのように CPU を貪り続けるものは、その逆の扱いになります。

なお CPU 使用率 100 パーセントそのものは悪ではありません。悪いのは、待たされている時間が長いことです。見るべき数字を取り違えないでください。