アカウント名:
パスワード:
この主な原因は、priorityを引き上げたprocessがすぐにscheduleされないことにあります。となると、対策としてはcpuよりもむしろkernelの改良になります。具体的には、preemptive kernelやpriority inversionの防止などになります。
が、これがマトモにできているのはSolarisぐらいしか思いつきません。追い付かなければならないのはわかっていますが...
こいつって、priority inversion対策はやっているんでしょうか? だいぶ前の記憶(2.4.1ぐらい)ですが、調べたらownerをtrackするようなlock primitiveがありませんでした(といってもshared-exclusiveやsemaphoreになるともはや近似的にしか扱えないが)。dispatch delayの分散はどんなもんなんでしょう?
あと、lock breakingというのはSVR4/MPと似たような問題を抱えていないでしょうか?
ちなみにFreeBSD-currentの方でも、preemptionはすでに有効になっています(i386とalphaで確認、他は不明)。なおかつ、system call共通部の全てと一部のsemanticsについてGiantがとれています。lock primitiveはSolarisとほぼ等価(adaptive lockは現在実装中)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
レスポンス (スコア:3, すばらしい洞察)
るものとしてはやはりレスポンスです。人間が感じられないギリギリまでは遅
くても全然構わないのですが、さすがにコンマ何秒や数秒も待たされると思考
が中断されてイラつきます。
CPUの性能はどんどん上がっているのに、常に微妙にイラつくぐらいのCP
Re:レスポンス (スコア:1)
この主な原因は、priorityを引き上げたprocessがすぐにscheduleされないことにあります。となると、対策としてはcpuよりもむしろkernelの改良になります。具体的には、preemptive kernelやpriority inversionの防止などになります。
が、これがマトモにできているのはSolarisぐらいしか思いつきません。追い付かなければならないのはわかっていますが...
Re:レスポンス (スコア:2, 参考になる)
http://www.tech9.net/rml/linux/ [tech9.net]
完全にまともと言えるかどうかはともかく、まぁ動くしアプリケーションによっては目に見えるレベルの改善がはかれます。
Re:レスポンス (スコア:1)
こいつって、priority inversion対策はやっているんでしょうか? だいぶ前の記憶(2.4.1ぐらい)ですが、調べたらownerをtrackするようなlock primitiveがありませんでした(といってもshared-exclusiveやsemaphoreになるともはや近似的にしか扱えないが)。dispatch delayの分散はどんなもんなんでしょう?
あと、lock breakingというのはSVR4/MPと似たような問題を抱えていないでしょうか?
ちなみにFreeBSD-currentの方でも、preemptionはすでに有効になっています(i386とalphaで確認、他は不明)。なおかつ、system call共通部の全てと一部のsemanticsについてGiantがとれています。lock primitiveはSolarisとほぼ等価(adaptive lockは現在実装中)。