sched autogroupについて

arch Linuxには2.6.38のパッケージが来ていて
デフォルトで有効になっていた
暫定対応時のようにcgroupディレクトリ以下にセッションID単位にファイルが出来て
みたいな確認方法が無いようなので、本当にきちんと動いているかは
負荷をかけてみるしかない　という感じ。

該当箇所のソースを読んでないので挙動については推測だけど
プロセス生成時に、自分でSIDを割り当てなければ何かとグルーピングされる。
デーモンプロセスについては追ってないんだけど、自分で呼び出した子プロセスに関してはグルーピングされてそう。
初期化処理の中でsetsidする奴は親プロセスになる、何から何処から呼び出しても。
これを考えると複数のサービスが混在するサーバとかでも有益なんじゃないかな。
特定サービスへの局所的な高負荷で他のサービス全体に悪影響を及ぼしたりしなくなる
と考えると非常に有益、コンテンツフィルタしたりウィルスチェックをするようなゲートウェイサービスには特に有益だろうな
F-Secureのウィルスチェックゲートウェイみたいなやつ。数あるサービスの中でもかなり重い部類に入るし、接続要求があると子プロ生成っていう動作を取るから効果的面な気がする。

「make -j70みたいなことをしても、ほかのプロセスに悪影響だしたりしないよ」
みたいなふれこみは正しかった。確かに動画を再生してもスムーズだった。
その最中にブラウザでtableが山ほど入れ子になったベンチマーク目的のページを開いても
きちんと描画も続いた、高負荷時はデスクトップ環境からみて「このプロセスは応答していません」扱いになることも多々あったんだけど
すごい効果だと思う。

ただそのmake -j70のほうの処理はほかの事をすれば完了は遅くなる。

１プロセスの実行速度よりも全体的な応答性を取りたい場合は
デスクトップ用途以外でも充分有効そう

kernel 2.6.38 リリース

やっときました
気になる日本での通称ミラクルパッチ(a.k.a."the patch that does wonders")ですが
デフォルトで有効かつ特別な対応なしに効いているようです。
これまで手動で対応していた人は起動スクリプトや設定ファイルに書いた変更を元に戻しておきましょう
もし、無効にしたい場合、または有効なはずなのにうまく動いてないという場合は
このファイルを確認しましょう　/proc/sys/kernel/sched_autogroup_enabled
ちなみに私はまだ試せてません
今日帰ったら早速やります
kernel newbieから超訳します

CPUに飢えたプロセスがいくつかあるとします。
まず同じセッションIDをもつ４つのプロセス
次にそれぞれ異なるセッションIDの２つのプロセス
automatic process groupingなし: [proc.1 | proc.2 | proc.3 | proc.4 | proc.5 | proc.6] automatic prosess groupingあり: [proc.1,2,3,4 | proc.5 | proc 6]
セッションIDとはUnixのプロセスが持つIDです。ps -eoで見ることができます。
setsid(3)によって新しいセッションIDが生成されて、そこからフォークした子プロセスに継承されます。
bashは起動のたびにsetsid(3)で新しいセッションIDを生成しますので、つまりは"make -j20"を実行しながら、何の問題もなくwebブラウズが出来たりするわけです。
この機能は2.6.24で実装されたgroup scheduringを利用しています。
/proc/sys/kernel/sched_autogroup_enabledで無効の設定を行うこともできます
(訳注たぶんbool）

つまりここでまとめられるプロセスというのが
何らかの親プロセスから生成された子プロセスがsetsidを行わない場合
(session IDが親プロセスと変わらない場合）
setsidで新しいセッションIDが生成された場合は
そのプロセスが親になって下にぶら下がるプロセスが、そのセッションIDでまとまる
ちなみにこれ、魔法でも何でもなくて過去実装された機能を有効活用するための実装
Linusが気に入ったのは効果も含めて、過去資産をスマートかつ有効に活用するアイデア
日本ではミラクルパッチとか魔法のパッチとか言われて
これだけで何倍高速化される　みたいな認識ですが
このパッチはスケジューリングにおける無駄を省くパッチになります
特にデスクトップ用途では色んなプロセスが山ほど立ち上がるので
そいつらが個別にCPU割り当てを要求して、その都度１つ１つを相手にするよりも
取りまとめて効率化することで無駄な遅延を起こさせないようにしましょう
という内容
つまりデスクトップ用途に限った話で言えばグループスケジューリングを
自動化してなかった今までがおかしいわけで、そこからやっとマシになった
高速化といってもプログラムの実行速度が速くなるわけじゃなくて
沢山の「ながら作業」をしてもプチフリしたり、描画が細切れに行われてるのを黙って待ったり
っていうイラっとするシチュエーションから開放されますよ　という話。
とどのつまりが、遅くなりにくくするパッチなわけ
（高速に動作するようになったのは動作の無駄が減ったスケジューラのみ）
よそ様のブログなどを見ていると「別に速くなった実感ないけどｗｗｗなにこれｗｗ」的な
書き込みをみるんだけど、単発で実行している以上に早くなったりはしないよと。
/.Jの200行パッチの記事とコメを真に受けたりすると、とっても恥ずかしいです
あのパッチから何故そんな話になるのかも理解できないなぁ・・・
フォアグラウンドアプリの優先度をブーストするとか
TTYのロック数を減らすことで高速化してるとか
TTYとGUIアプリの相互関係について議論とか
しかもそういうのに限って高いモデがついてる
悪意はないのだろうけど、外から見に来てる人間は有害だよなぁ・・・
間違ってても高モデで「参考になる」とかなら、それが正しいと勘違いするバカが量産されるじゃないのさ
あとLinusが大改造を嫌う　とかね。いるんだよああいうの真に受けてブログとか酒の席とかでわかったように偉そうな批判する奴がさ。
Linuxが嫌がるのは「俺様専用実装ｶｯｺｲｲ」とか
ただの名前変更のために超大なレビュー時間を割かれるとか
規模に関わらず、さっさとテストしたいパッチなのにも関わらずに
つべこべ議論して、何だかんだグダグダ言いながらレビューやテストから逃げたいがために没にしようとしてるダメメンテナが引き起こしたフレーム紛いの
なが～いスレッドだったり
むしろ商用利用とかって観点でみるとLinusはダイナミックすぎるところがあるから
冷や冷やするくらいだ。そんな大規模なパッチ今いれないでーくらいのね。