[OSASK 2966] from OSASK BOARD

[Itou_Tetsuya <mone !Atmark! imasy.or.jp>]

このメールは、OSASK伝言板に書き込まれた内容です。
この書き込みに返事を書く場合は、下のURLから書き込みを行なって下さい。


http://www.imasy.or.jp/~mone/osask/index.cgi?REFER=3c482bc4_12030

From: 川合秀実
Message-ID: 3c482bc4_12030
Date: 2002/01/18 23:05
Subject: Re: ファイルの概念

[OSASK 2963]へのレスです。

>とりあえずグローバルやインナーのような明らかに対義語がある
>言葉を組み合わせるのは変ですよね。
>実質的にインナーレベルはプライオリティではないですので、
>グローバルレベルを単にプライオリティと呼べばいいと思います。
>インナーレベルではlottery schedulingのようなことを実現しよう
>としてるのだと思いますが、そこでは配分比を決めるパラメータを
>ticketとよんでますね。

　なるほど。これはなかなか良いと思うので、ページに併記しておくことにしま
す。・・・ちなみに、あそこには出てきませんでしたが、タスクの制御にはロー
カルレベルというものもあります。しかしこれもグローバルとの対比という意味
ではないので(もとは対比だったのですが、インナーが入ってややこしくなった)
、分かりやすい語を探すべきかもしれません。まあ、今はいいです。

>排他というと同じグローバルレベルをもったプロセスは他に無いって
>意味になりませんか？その文脈では共存はその逆と。

　そうでしょうか？タスク集団をグローバルレベルごとに分けて、1つがアクテ
ィブな間は他を排除しているんですから、「排他」というのは別におかしくない
と思いますが。そして、その中の配分はインナーでやるので、それぞれのタスク
は順番にアクティブになるのですから、共存的というのはあっていると思います
。・・・ただ問題は、「排他」「共存」という言葉が対義語なので、そういう風
に捉えるとグローバルとインナーが正反対の性質を持つと思われるかもしれませ
ん。「縦軸」に対する「横軸」のような関係なのですが・・・。だからまあ、対
義語には違いないんですが・・・。

(グローバルレベルの必要性)
>たしかにそうですね。
>もし本当に汎用のOSでそんな需要があるのでしたら、
>相対的な半順序みたいなのが定義できる方が便利ですね。

　そりゃあ便利でしょう。しかしいくら便利だからと言ってほいほいと柔軟にし
ていけば、それだけ複雑になります。僕は今の設計が、かなりよいバランスを保
っていると思っています。

（スリープという状態の代わりに、専用のグローバルレベルがあること）
>僕はソースを読まずに言ってるので申し訳ないですが、
>それぞれのグローバルレベルにタスクキューがあるような構造を
>想像しているのです。

　そのご想像は正しいです。そのとおりです。

>そうするとスリープレベルのプロセスはスリープキューにつながれる
>と思いますが、スリープしているプロセスをキューにつないだり
>外したりするのは無駄な作業かなと心配していました。

　確かに無駄な作業です。数回のメモリアクセスでしかありませんが。

　しかしタスクにstatusを設けて、statusを変更するためのファンクションを別
に作り、グローバルレベルへ復帰する際もそれがスリープからの復帰なのか、そ
れともグローバルレベルの変更なのかを区別して・・・なんていうのは、僕の求
めるシンプルさとはかけ離れていると思います。コードが長くなった分のメモリ
アクセス数増加を補いきれないでしょう。

>アイドルも一回メモリ参照が増えますよね。
>コードを小さくする方が優先事項なのかもしれませんが、
>現代のプロセッサではメモリアクセスが一番パフォーマンス的に
>痛いと思います。

　メモリアクセスは、キャッシュに当たりさえすればたいしたことはありません
。しかし分岐が増えたり、コードが多くなったりするのは、どうでしょう？分岐
も分岐予測が当たればどうってことはないですが、毎回同じ分岐をするわけでは
ありませんし、だから予測はある程度はずれます。コードが増えれば、もちろん
フェッチのためのメモリアクセスは増えます（キャッシュにヒットしたとしても
そのコードをキャッシュに保持するために他のデーターやコードがキャッシュか
ら追い出されているでしょう）。

　パフォーマンスについては、今ここで議論しても水掛け論です。両方を作って
ベンチマークするべきです。それまでは、確実な結論は出せません。

>>　結局インナーレベルが効いてくるのは、滅多にスリープしないようなタスクが
>>複数走っている場合のみです。
>これだと実質的にインナーレベルは意味をなさないですよね。

　そういう場合しかなければ、そのとおりです。

　しかし重いアプリケーション(＝めったにスリープしないアプリ)が走っている
場合もあるでしょう。そしてこういう時こそ配分比を決めたいのであって、スリ
ープばかりするような瞬時に終わるアプリケーション(キー入力やタイマー待ち
が多いもの)の時間比を正確に設定できても面白くありません。

>もしこのような方針で行くのならrdtscでそのプロセスが実際に
>使ったクロック数を計測してできるだけ配分比に近付くように
>スケジュールするような実装にしたらどうでしょう。

　それは、キーを入力しても配分比の維持のために入力処理が待たされるような
システムですか？いくらなんでも、そんなのは現実的ではないでしょう。

>実際にはIOとか他の方面を考慮する方が配分比より
>ずっと意味があるかもしれませんが。

　それは単純に実現できるような仕組みなんでしょうか？そうであれば、採用し
たいです。

>>　・・・しかし、確かに僕の記述はあいまいだったかもしれません。比較の対象
>>としてUNIXではなく、LinuxやFreeBSDなどと書くべきだったかもしれません。
>それならわかりやすいですね。

　註を加えておきました。