実行速度の遅いiwup_tsk2010年02月07日 00時46分16秒

現在開発に携わっている案件でμITRONを使っています。

このμITRONのiwup_tsk()が異常に遅い。 クロック周波数などは伏せますが、割り込みハンドラ内での実行速度に5us~80usというように幅がある。 サービスコールの前後でポートに出力してオシロスコープで観測した結果です。

私の認識ではiwup_tskはμITRONのサービスコール(システムコール)のなかでも最上級でシンプルで実行速度が速いつもりでいました。この認識を覆す遅さです。

遅いというよりも実行速度に幅があることが問題。こんなに幅があると割り込みハンドラの設計が出来ない。割り込み保留可能時間を見越せないということで非常に問題があります。

これは開発担当者の実装設計がまずいといわざるを得ないです。

私の認識では「iつきサービスコール」は以下のような実装である必要があると思っています。

  • 遅延ディスパッチは当然
  • 遅延ディスパッチの前の事前のキュー繫ぎ替え処理は関数本体では行わない
  • 関数本体では要求のためのマークをつけるだけ
  • キュー繫ぎ替え、割り込み復帰時のディスパッチ用のスタック操作は遅延ディスパッチ処理の一環として実施

実行速度に幅がある理由は想像では以下です。

  • 関数本体で遅延ディスパッチの事前準備まで実施
  • つまりレディキュー、待ちキューの繫ぎ替え処理まで行っている
  • 処理時間の違いはキューに繋がっているタスクの数に依存
  • キュー繫ぎ替えの結果によってディスパッチするタスクが割込みが入る以前のタスクかそうでないかによってコンテキストの扱いが変っている

遅延ディスパッチの実装上の意味を割り込みハンドラから抜けるタイミングまで遅らせて次の実行タスクにジャンプする程度のことだと勘違いしていないですかね。開発担当者は。

例えばサービスコール発行が一つではなく、複数の場合はこの実装だと処理時間の無駄が積算されます。

まあ、そんなに単純な理由ではないのかもしれませんけど。 ソースコード見ないことには真相は不明です。

いずれにしてもこんなに性能が悪いμITRONが出回っているのだとするとμITRONを使用したシステムの基本設計の最初の段階でサービスコールの実測作業が必要だということになります。 特に「iつきサービスコール」については実測必須です。 μITRONが速いということも主張できなくなりますね。

・・・・というところまで書いてきて、検索してたら使っているものとは違いますがdoxygenでTOPPERSのソース公開されているところを見つけました。結論としてはTOPPERSの実装が諸悪の根源みたいです。

これを見るとiwup_tsk()とwup_tsk()の実装はほぼ同じ。iwup_tsk()ではディスパッチを実行せずにディスパッチが必要かどうかのフラグを立てているところが違う。 だめじゃん。もっと前の段階の処理を省略しないと処理速度が一定にならないです。ディスパッチが必要かどうかを判定する処理自体も遅延させないと。つまり「wait_complete(tcb)」って関数コールはここでやったらだめです。キューの状態に依存する処理は処理速度が一定にならないですから。

こちらにも解説がありますね。

このような状況が放置されているのは最近のμITRONのカーネルの開発者と実際の組込みシステムの開発者の意識が違いすぎるということなのかもしれません。μITRON2.0の時代は現場の人間がμITRONカーネルの開発をしたので学者じゃなかったと思います。

今のμITRONカーネル開発者は「学者」ってことです。本当の性能要件が分かっていない。 割り込みハンドラの実装部分から設計をやり直したいですね。 メモリ保護とかよりもこっちが先でしょ。