> だからバランスよくと表現したんだけど。LinuxはPC用OSだよ?
> DVDとか見るときとかどうするのさ。これってほとんどCPUバウンドなプロセスだよ。

それこそ、リアルタイム・スケジューリングを使うべきアプリケーション
じゃないの？ 今はカーネルが、どう優先度を自動的に推測すべきかって
話をしているわけでしょ。リアルタイム・スケジューリングの場合、
ユーザーが指定した優先度が固定的に使われるんだから、そもそもそういう
問題は発生しないよ。

> なんでここまで粘着かというとオライリーの「LINUX カーネル」のP330に
> 「I/Oバウンド型プロセスを優先する仕組は万能ではない」
> という節があるから。俺もこれを見て納得してたんだけどそうではないという。
> それで混乱しているわけさ。

え？ その記述は正しいよ。
俺は、ベストだとは言ったかもしれないけど、万能だなんて言ってないけどな。
カーネルの行う優先度の推測は、所詮推測に過ぎないんだから、向かない
応用はあるし、だからこそリアルタイム・スケジューリングとかが必要に
なるわけでしょ。
でも、TSS 用の優先度変動型スケジューリング・ポリシーとしては、I/Oバウ
ンド・プロセスを優先させる以外に良いやり方はないと思う。というか、CPU
バウンド型プロセスを優先させたら、取り返しのつかないことになる。

> > もし信じられないなら、p->couter が大きい方を優先する代わりに p->counter
> > が小さい方を優先するように goodness() を書き換えて試してごらんよ。そん
> > なことをしなくても、ちょっと考えれば分かる筈だと思うんだが。
>
> それって優先度が逆転してるじゃん（笑）

そう。君の主張していた、TSS スケジューリングにおいて CPU バウンド型
プロセスを優先させるっていう方針は、つまるところ、そういう意味なわけ。
やっと分かったかな。

> こういう部分はLinuxの各所に見られるね。アルゴリズムをシンプルにするこ
> とによって速く動かそうという感じ。VM とか。その代わり必要だと思ったら
> ガンガン詰め込む。

この、必要だと思ったらってところの判断基準に納得いかない点があるんだよなあ。
今回の応用の場合は作り込みで問題を回避できたけど、一般論としては回避で
きないこともあると思うんだが。

> スケジューラの件も kernel-ml あたりでプリエンプティブなスケジューラ
> のパッチが流れてきてるんでそのうち入るのではないかな。

プリエンプティブ化と この件は、関係ないのでは？

> そういや君の案件ってリアルタイムプロセスにして動かすという手はなかったの?

リアルタイム・プロセスにするにはルート権限いるでしょ。
この特定の問題のためだけに setuid root にするよりは、sched_yield() で
スケジューラの変な挙動を回避する方が、マシな解決策だと判断したわけ。