Linuxカーネル用リアルタイムスケジューリングモジュール

Vol. 0
No. 0
1959
情報処理学会論文誌
Linux カーネル用リアルタイムスケジューリングモジュール
加 藤 真 平
†
山
崎
信
行†
本論文では，与えられた時間制約のもとで CPU 資源を最大限に使用可能なリアルタイム Linux
の実現に向けて，Linux カーネル用リアルタイムスケジューリングモジュールを開発する．まず，高
負荷状態における十分なリアルタイム性と予測可能性の提供を目的として，固定優先度の利点と動的
優先度の利点を兼ね備えたスケジューリングアルゴ リズムを提案する．提案アルゴ リズムは理論的な
性能の面で従来の固定優先度アルゴ リズムと同等以上であることが保証され， Linux カーネルのスケ
ジューラ実装に対する親和性も高いという利点がある．次に，拡張性の高いリアルタイム Linux の
実現のために，カーネルの修正を最小限に抑え，新規のスケジューリングアルゴ リズムをカーネルモ
ジュールとして組み込むことを可能にするフレームワークを提案する．シミュレーションによる評価
の結果，提案アルゴ リズムは従来の固定優先度アルゴ リズムよりも約 10∼15%高い CPU 使用率でも
リアルタイム性を保証できた．また，実機による評価の結果，開発したカーネルモジュールを組み込
むことで，ネイティブな Linux に比べて高負荷状態における低優先度タスクのデッド ラインミス率
を最大で約 70∼90%削減することができた．
Real-Time Scheduling Module for Linux Kernel
Shinpei Kato† and Nobuyuki Yamasaki†
In this paper, a real-time scheduling module for the Linux kernel is developed for the
achievement of Real-Time Linux that is able to utilize sufficient CPU resource under given
timing constraints. We first present a scheduling algorithm with the advantages of both fixedpriority and dynamic-priority for the purpose of providing sufficient real-time capability and
predictability in high-load situations. The presented algorithm is at least as effective as a
traditional fixed-priority algorithm in terms of theoretical schedulability, and its design is
suitable for the scheduler implementation of the Linux kernel. We then propose a framework
that enables new scheduling algorithms to be installed as kernel modules without major modification to the kernel, for the achievement of scalable Real-Time Linux. Simulation results
show that the presented algorithm guaranteed all jobs to be schedulable at about 10∼15%
higher CPU utilization than a traditional fixed-priority algorithm. In addition, experimental
results in real environments show that the deadline miss ratio of low-priority tasks in high-load
situations was reduced at most 70∼90% by installing the developed kernel module, compared
to the native Linux.
る．Linux を利用することでソフトウェアライブラリ
1. は じ め に
やデバイスド ライバ等のソフトウェア資産が再利用可
組み込みシステムの高機能化に伴い，その基盤とな
能になり，さらには技術者の確保も容易になることか
るオペレーティングシステム（ OS ）には様々な機能お
ら開発コストを大きく削減できることが期待できる．
よび性能が求められている．とりわけ，マルチメディ
しかしながら，Linux は汎用システム向けに設計され
ア処理や多様な I/O デバイスを必要とする組み込みシ
た OS であり，組み込みシステムに求められるリアル
ステムでは，ソフトウェアライブラリやデバイスド ラ
タイム性や応答性に関しては改善の余地がある．
イバの利用が不可欠であり，従来の専用組み込み OS
マルチメディアシステムに代表されるソフトリアル
によってすべての機能を提供することは不可能に近
タイムシステムでは，アプリケーションの処理量が比
い．このような背景から，組み込みシステムの分野で
較的大きいため，与えられた時間制約のもとで CPU
は汎用 OS である Linux に対する期待が高まってい
資源を最大限に使用できることが求められる．時間
制約下での CPU 使用率の上限は，しばしば OS の
スケジューリングアルゴ リズムに依存する．理論的
† 慶應義塾大学
Keio University
に最適なアルゴ リズムとして Earliest Deadline First
1
2
1959
情報処理学会論文誌
6)
（ EDF ）
が広く知られているが，優先度が動的に変
ネイティブの Linux と比較して評価する．6 章で本論
わることから予測可能性の低下と実行時オーバヘッド
文の結論を述べる．
が問題となる．一方，多くのリアルタイム Linux が
2. 関 連 研 究
採用している固定優先度アルゴ リズムは，実装が簡単
であるうえに，優先度の低いタスクが優先度の高いタ
スクのデッド ラインミスを誘発することはなく，必ず
優先度の低いタスクが先にデッド ラインミスを起こす
ことが保証される2) ．しかしながら，高負荷状態にお
いては，最適な固定優先度アルゴ リズムである Rate
6)
Monotonic（ RM ）
を用いたとしても，最悪の場合
には CPU 使用率が 69%を超えると時間制約が破綻し
てしまう可能性がある．高品質なリアルタイムシステ
ムを構築するためには，固定優先度アルゴ リズムの簡
潔さと予測可能性を継承しながらも高負荷状態におい
て十分なリアルタイム性を提供可能なスケジューリン
グアルゴ リズムが必要である．
Linux カーネルはオープンソースとして日々改良が
重ねられているソフトウェアであり，マイナーバージョ
ンの更新によってもカーネルに大きな修正が施される
RT-Linux10) では，Linux のスケジューラやプロセ
ス間通信機能を修正して，Linux カーネル自体を優先
度の低い 1 つのタスクとしてスケジューリングする．
リアルタイムタスクと Linux を切り分けているため，
すべてのリアルタイムタスクはカーネルレベルで実行
されることになり，カーネル自体の応答性が低下する
可能性があるという問題がある．また，リアルタイム
タスクはカーネルモジュールとして作成する必要があ
るので，従来よりもアプリケーションの作成が難しく
なるという欠点もある．
ART-Linux11) はカーネル自体にリアルタイム性を
持たせるように設計されたリアルタイム Linux であ
る．RT-Linux とは異なり，従来の Linux プログラミ
ングとの互換性が高く，ユーザ空間でもリアルタイム
タスクを実行できるので，安全性が高いことやプログ
ことも少なくない．従来のリアルタイム Linux のよう
ラミングが簡単になるといった利点がある．しかしな
にカーネルに直接修正を加えるアプローチでは，カー
がら，リアルタイムタスクには単純に固定優先度が与
ネルに大きな修正が施された場合に再度修正部分の
えられるだけなので，リアルタイムタスクが複数存在
設計を見直す必要があり，開発コストが高い．最新の
するシステムにおいて CPU 使用率が高くなってしま
Linux カーネルに柔軟に対応するためには，カーネル
うと，最高優先度タスクの応答性は確保できても全体
自体の修正を最小限に抑えることが求められる．
的なリアルタイム性の低下は防ぐことができない．
リングモジュールを開発する．まず，高負荷状態にお
TimeSys Linux9) は固定優先度スケジューリングに
加えて，Resource Kernel8) や Portable RK7) といっ
た資源予約技術を導入しており，高負荷状態において
も任意のタスクのリアルタイム性を保証することがで
ける十分なリアルタイム性と予測可能性の提供を目的
きる．ただし，システム全体のリアルタイム性は固定
として，固定優先度の利点と動的優先度の利点を兼ね
優先度スケジューリングの性質に依存する．また，固
備えたスケジューリングアルゴ リズムを提案する．次
定優先度スケジューラ等のプリミティブな機能以外は
に，拡張性の高いリアルタイム Linux の実現のために，
カーネルモジュールとして提供しているため，システ
本論文では，与えられた時間制約のもとで CPU 資
源を最大限に使用可能なリアルタイム Linux の実現
に向けて，Linux カーネル用リアルタイムスケジュー
カーネルの修正を最小限に抑え，新規のスケジューリ
ム設計者は必要に応じて機能を追加，削除することが
ングアルゴ リズムをカーネルモジュールとして組み込
でき，拡張性が高いといえる．
むことを可能にするフレームワークを提案する．最終
的に，最新の Linux カーネル 2.6.25 に 1 行の修正を
加えるだけで開発したモジュールを組み込むことがで
3. スケジューリングアルゴリズム
本章では，固定優先度アルゴ リズムの簡潔さと予測
き，高負荷状態におけるリアルタイム性を大きく改善
可能性を継承しながらも高負荷状態において高いリ
できたことを示す．
アルタイム性を提供可能なスケジューリングアルゴ リ
本論文の構成は以下のとおりである．次章ではリア
ルタイム Linux の関連研究について述べる．3 章では
新規のスケジューリングアルゴ リズムの設計と解析を
ズムを設計し，リアルタイム性を保証するためのスケ
ジュール可能性判定の解析を行う．
3.1 設
計
行う．4 章では提案アルゴ リズムを実装したカーネル
まず，固定優先度アルゴ リズムによるデッド ライン
モジュールの設計と実装を詳述する．5 章では開発し
ミスを考える．図 1 は周期の短いタスクに高い優先度
たカーネルモジュールを組み込んだ Linux の有効性を
を与える Rate Monotonic （ RM ）を用いて，実行時
Vol. 0
No. 0
Linux カーネル用リアルタイムスケジューリングモジュール
T1
T2
ts
deadline miss
T3
e hp
ei
Thp
Ti
x i(t s)
zero laxity
di
critical laxity
図 1 RM スケジューリング
Fig. 1 RM scheduling.
T1
3
図 3 Critical Laxity
Fig. 3 Critical Laxity.
preemption
T2
T3
• 現在のタスクより優先度の高いタスクの周期が開
始された場合
• 現在のタスクが実行可能ではなくなった場合（実
行完了やスリープ ）
よって，RMZL をそれらの OS に実装する場合には，
余分にスケジューラを起動しなくてはならない．また，
zero laxity
図 2 RMZL スケジューリング
Fig. 2 RMZL scheduling.
ゼロ余裕時間状態になるタイミングによっては細粒度
のタイマ起動が必要になってしまうことや，余裕時間
が 0 になってから最高優先度を与えてもタスクの実行
完了はデッド ラインと同時刻であり実システムでは危
間が同じで周期が異なる 3 つのタスク T1 ，T2 ，T3 の
険が伴うことも問題となる．
スケジューリングを行う様子を示している．この例で
しまう．そこで，Zero Laxity（ゼロ余裕時間）によ
本論文では，Zero Laxity の概念を拡張した Critical Laxity（ 危険余裕時間）を提案する．時刻 ts を
RM スケジューリングにおける任意のスケジューリン
グポイント ☆とする．ここで，RM は固定優先度アル
る動的最高優先度割当て3) の概念を導入する．ゼロ余
ゴリズムであり，スケジューリングポイント ts の出現
裕時間とは，余裕時間が 0 になった状態を指す．タス
は上述の 2 通りに限定されることに注意されたい．時
ク Ti の時刻 t における余裕時間 xi (t) は，Ti のデッ
刻 ts における最高優先度タスク Thp の残り実行時間
ド ライン di と残り実行時間 ei を用いて式 (1) によっ
を ehp とすると，条件式 (2) が成り立つ場合にタスク
て定義される．
Ti の余裕時間 xi (ts ) を Critical Laxity と定義する．
は，優先度の低い T3 は，優先度の高い T1 と T2 にブ
ロックされ，結果としてデッド ラインミスが発生して
xi (t) = di − (t + ei )
(1)
余裕時間が負の値になってしまったタスクは並列処
理を行わない限りデッド ラインまでに実行を完了す
ることは不可能なので，余裕時間が 0 になった時点
（ xi (t) = 0 となる時刻 t ）で最高優先度を与えない
xi (ts ) < ehp
(2)
以降，タスクの余裕時間が Critical Laxity である
ことを危険状態という．RM スケジューリングにおい
て危険状態になったタスクは，その時点で最高優先度
を与えない限り，デッド ラインミスを回避することは
限りデッド ラインミスを回避することはできない．こ
できない．図 3 の例を用いて説明する．タスク Ti が
の概念を RM に取り入れたアルゴ リズムを RM Zero
時刻 ts に危険状態になったとする．xi (ts ) < ehp で
Laxity（ RMZL ）と定義する．
図 2 は RMZL を用いて，先の 3 つのタスクをスケ
あるため，Thp の実行が完了する前に Ti の余裕時間
は必ず 0 になる．よって，Ti は必ずデッド ラインミ
ジュールする様子を示している．T3 の余裕時間が 0 に
スを起こす．ここで，危険状態になった Ti に最高優
なったときに，最高優先度を与えることでデッド ライ
先度を与えれば，Ti はデッドラインミスを起こすこと
ンミスを回避できることがわかる．しかしながら，T3
はない．本論文では，RM スケジューリングにおいて
が最高優先度になったことで T1 の実行がプリエンプ
危険状態になったタスクに最高優先度を与えるアルゴ
ションされることに注目されたい．4.1 節で後述する
リズムを RM Critical Laxity（ RMCL ）と定義する．
とおり，Linux や多くの商用リアルタイム OS が採用
図 4 は RMCL を用いて，先の 3 つのタスクをスケ
する固定優先度アルゴ リズムでは，スケジューラが起
動される条件は以下の 2 通りに限定される．
☆
スケジューラ起動時刻．
4
1959
情報処理学会論文誌
優先度アルゴ リズムの利点の 1 つは，優先度の低いタ
T1
スクからデッド ラインミスを発生するという予測可能
性がある点である．よって，本論文ではこの性質を保
T2
つために，危険状態になって最高優先度が与えられる
のは，そのほかのタスクが危険状態にならない場合に
T3
限定する．この制限により，理論的な性能低下を一切
critical laxity
起こすことなく，効果的にリアルタイム性を改善する
図 4 RMCL スケジューリング
Fig. 4 RMCL scheduling.
ことが可能となる．
3.2 スケジューリング解析
システム全体で一定のリアルタイム性を保つため
deadline miss
には，スケジュール可能性判定によって実行可能なタ
スクセットをアド ミッションコントロールする必要が
T1
ある．本論文では，伝統的な Response Time Analy1)
sis（ RTA ）
を応用して RMCL アルゴ リズムのスケ
T2
ジューリング解析を行う．以降，タスク Ti の周期を
T3
critical laxity
図 5 Critical Laxity によるデッド ラインミス
Fig. 5 Deadline miss due to Critical Laxity.
pi ，
（ 最悪）実行時間を ci と表記する．すなわち，Ti
は pi 時間ごとに ci の実行時間をもつジョブを生成す
るものとする．また，相対デッド ラインは pi とする．
固定優先度スケジューリングでは，各タスク Ti は
自分よりも高い優先度を割り当てられたタスクからの
ジュールする様子を示している．T3 が危険状態になっ
み干渉を受ける．この性質を利用して RTA では公式
た時点で最高優先度を与えることでデッド ラインミス
(3) を用いて Ti のジョブの最悪応答時間 Ri を求める．
ここで，表記の簡略化のため，すべての i に対して優
先度の大小関係は Ti ≥ Ti+1 であるものとする．
を回避できており，かつ余分なスケジューラ起動を必
要としていないことがわかる．実際，RMCL による
スケジューラ起動回数は RM によるそれと同じであ
る．また，各スケジューリングポイントで危険状態に
なったタスクが存在するかど うかを確認する以外は，
Ri =
i−1 Ri
k=0
pk
ck + ci
(3)
RM と同じ振舞をする．
RMCL の最大の特徴は，スケジューラ起動やラン
すべての Ti に対して Ri ≤ pi が成り立っていればタ
キュー操作等のコストは RM とほぼ同等であり，か
逆に 1 つ以上の Ti が Ri > pi となるようであれば
つ RM と同等かそれ以上の CPU 使用率でも時間制
デッド ラインミスが発生する可能性がある．
約を満たすことができる点である．すなわち，理論的
RMCL によっても必ず時間制約を満たせることが保
RMCL スケジューリングでは，あるタスク Ti が
Ri > pi となった場合でも Critical Laxity による最高
優先度割当てによって Ti のデッド ラインミスを回避
証される．RM スケジューリングでは危険状態になっ
することが可能である．デッド ラインミスが発生する
たタスクが必ずデッド ラインミスを起こしてしまう事
状況は，Ti に最高優先度を与えたことでほかのタスク
実から，このことは自明である．
Tj が危険状態になってしまう場合に限られる．また，
Ti が危険状態になって最高優先度が与えられた場合，
に RM によって時間制約を満たせるタスクセットは
RMCL スケジューリングでは，危険状態になったタ
スクセットはスケジュール可能であることが保証され，
スクに最高優先度が与えられるが，この優先度付けに
Ti の実行は早まることがあっても遅れることはない．
よって元々優先度の高いタスクがデッド ラインミスを
よって，影響を受けるのは Ti よりも優先度の高いタ
起こすことも考えられる．図 5 の例では，T3 の実行中
スクのみであることに注意されたい．この性質を利用
に優先度の高い T1 の周期が始まったが，T3 が危険状
して RMCL のスケジュール可能性判定式を導き出す．
態であるために T3 に最高優先度を与えてスケジュー
まず，優先度の低いタスクから順に RTA の公式 (3)
リングを行っている．しかしながら，これが原因とな
を用いて最悪応答時間を算出する．すべての Ti に対
り T1 も危険状態となり，結果としてデッド ラインミ
して Ri ≤ pi であればタスクセットはスケジュール可
スを起こしてしまっている．先に述べたように，固定
能であることは自明である．ここで，Ti が Ri > pi に
Vol. 0
No. 0
Linux カーネル用リアルタイムスケジューリングモジュール
なったとする．Critical Laxity によって最高優先度を
pick next task() {
与えない場合に Ti がデッド ライン pi 以内に消費しき
class = rt sched class;
for ( ; ; ) {
p = class->pick next task();
if (p)
return p;
れない最悪実行時間 Wi は式 (4) で表せる．
Wi = max{Ri − pi , ci }
(4)
よって，Critical Laxity によって Ti に最高優先度
が 割り当てられ ると，最悪の場合にはすべての Tj
（ j < i ）の実行が Wi 時間遅れることになる．その
class = class->next;
}
結果，Rj > pj となる Tj が存在すればタスクセット
はデッド ラインミスを発生する可能性がある．いいか
えると，すべての Tj が式 (5) を満たしていればタス
クセットはスケジュール可能であることが保証される．
Rj + Wi ≤ pi
5
}
図 6 pick next task 関数
Fig. 6 pick next task function.
(5)
4. スケジューリングモジュール
3 つのスケジューリングクラスはタスク選択用に各々
pick next task 関数を実装し ている．pick next task
本章では，RMCL を実装したカーネルモジュールで
関数は ，常に rt sched class の pick next task 関数
ある Real-time scheduling（ Resch ）モジュール☆ の
を 優 先し て 実 行 す る ．3 つ の ス ケジュー リン グ
設計と実装を行う．
クラ スは next メン バに よって ，rt sched class →
fair sched class → idle sched class の順にリストされ
ており，rt sched class の pick next task 関数によって
4.1 Linux スケジューラの概要
Linux カーネル 2.6.23 以降，スケジューラの 実
装は 3 つのクラス（ rt sched class，fair sched class，
実行可能なリアルタイムタスクが得られない場合のみ，
idle sched class ）に分けられている．クラスは構造体
として定義され，各クラス専用のタスク選択関数やタ
スクキュー操作関数等へのポインタがメンバとなって
いる．そのため，リアルタイムタスクのスケジューリン
次のスケジューリングクラスの pick next task 関数を
グ（ rt sched class ）をそのほかのタスクのスケジュー
リング（ fair sched class，idle sched class ）から切り
離して実装することができるようになった．本論文で
は，このクラス化を有効利用する．
Linux カーネルでは，スケジューリングは一括して
schedule 関数で行われている．schedule 関数の大まか
な内容は以下のとおりである．
( 1 ) プリエンプションの無効化やランキューのロッ
ク獲得
( 2 ) 現在実行中のタスク（ prev ）の状態チェック
(3)
(4)
(5)
次に実行するタスク（ next ）の選択
prev から next へコンテキストスイッチ
プリエンプションの有効化やランキューのロッ
ク解放
スケジューリングアルゴ リズムの仕事は次に実行す
るタスクを決定することなので，それに関連するのは
ステップ (3) だけである．Linux のスケジューラ実装
では，ステップ (3) は pick next task 関数として用意
されている．その疑似コード を図 6 に示す．
実行する．ここで，各クラスの pick next task メンバは
関数ポインタであり，rt sched class の pick next task
はカーネル内に別途実装された pick next task rt 関
数を参照し ていることに注意されたい．実際には ，
pick next task rt 関数が実行可能なタスクの中で固定
優先度が最も高いタスクを選択することになる．
4.2 Linux カーネルの修正
rt sched class の pick next task メンバは関数ポイン
タなので，この関数ポインタの参照先を変更できれば，
独自の pick next task 関数をカーネルモジュール内に
用意して外部から Linux カーネルに組み込むことが
できる．Linux カーネルでは，rt sched class は静的な
構造体として以下のように宣言されている．
const struct sched class rt sched class
よって，const を取り除いてシンボルをエクスポート
すれば外部のカーネルモジュールから pick next task
関数を上書き可能になる．本論文では，以下の 1 行の
修正を加えた Linux カーネルを Linux+と呼ぶ．
struct sched class rt sched class
Linux+ではこれ以上の修正をカーネルに施すこと
はない．Linux カーネルの今後のバージョンで上記の
変更が行われることがあれば，カーネルに一切修正を
施すことなく Resch モジュールを利用できるようにな
☆
http://www.ny.ics.keio.ac.jp/˜shinpei/t-rex/よりダ ウン
ロード 可能．
る．現在，この変更が可能かど うか Linux 開発コミュ
ニティと議論中である．
6
1959
情報処理学会論文誌
.KPWZMGTPGN
TVAUEJGFAENCUU
RKEMAPGZVAVCUM
4GUEJOQFWNG
RKEMAPGZVAVCUMATV
struct rt data {
long
long
long
long
RKEMAPGZVAVCUMATGUEJ
$GHQTGKPUVCNN
#HVGTKPUVCNN
図 7 Resch モジュールのインストール
Fig. 7 Install of Resch module.
period;
deadline;
wcet;
remaining time;
}
図 8 rt data 構造体
Fig. 8 rt data structure.
4.3 フレームワークの設計の実装
本フレームワークでは，まず新規のスケジューリン
グアルゴ リズムを pick next task resch 関数として
Resch モジュール内に実装する．前節のカーネル修正
により，外部のカーネルモジュールから rt sched class
の pick next task 関数ポインタの値を上書き可能になっ
ているので，図 7 に示すように，Resch モジュールのイ
うに登録しておく．たとえば，以下のように resch init
関数を実行したとする．
resch init(99);
実際には resch init 関数は以下のコード を実行する．
((long*)data)[0] = ID INIT;
に新規のスケジューリングアルゴ リズムを組み込むこ
((long*)data)[1] = 99;
fd = open(“/dev/resch”, O RDWR);
write(fd, data, sizeof(data));
ID INIT は関数の種類を示す ID 値である．Resch モ
ジュールの resch write 関数では ID の値をチェックし
とができる．
て，それに対応した処理を行う．
ンストール時にポインタの参照アドレスを Linux カー
ネル内の pick next task rt 関数からモジュール内の
pick next task resch 関数に書き換えることで，Linux
Resch モジュールでは，スケジューリングのために
以下の 4 つのカーネル関数が用意されている．
• int resch init(long priority)
• int resch exit(void)
• int resch run(long period, long timeout)
• int resch yield(void)
resch init 関数は，呼び出し元のアプリケーションプ
ログラム（タスク）を Resch モジュールが管理するタ
スクキューに挿入する．引数にはタスクの優先度（ pri-
リアルタイムスケジューリングを行うためには，各
タスクにデッド ラインや実行時間等のデータを関連
付ける必要がある．Resch モジュールでは，これら
のデータを rt data 構造体として定義した．図 8 に
代表的なメンバを示す．wcet は最悪実行時間である．
Resch モジュールはタスクの実行時間を追跡してい
き，resch yield 関数が実行されたときの実行時間がそ
れ以前の周期での最悪実行時間（ wcet ）より大きかっ
たら wcet の値を更新する．remaining time はタスク
ority ）を指定する．Resch モジュールによる管理を終
了したい場合は resch exit 関数を実行する．resch run
関数は，実際に Resch モジュールによるスケジュー
リングを開始する．引数にはタスクの実行周期（ period ）と何マイクロ秒後に最初の周期を実行開始する
がある．Resch モジュールでは，実装対象を Linux の
か（ timeout ）を指定する．resch yield 関数は，ほかの
タイムスライス情報を必要としないアルゴ リズムに
タスクに CPU を譲る関数であり，周期タスクは各周
Resch モジュールはカーネル空間で動作し，タスク
制限し ，task struct 構造体から参照可能な long 型の
rt.time slice メンバを rt data 構造体へのポインタを格
納する変数として使用する．具体的には，rt data 構
は一般的にユーザ空間で動作するので，ユーザプログ
造体と task struct 構造体の関連付けは，resch init 関
ラムからカーネルモジュールの関数は直接実行はでき
数が実行されたときに以下のように行う（適宜省略）．
ない．そこで，Resch モジュールを仮想的なキャラクタ
関数が /dev/resch に write システムコールを発行する
rt data *rt = kmalloc(sizeof(*rt));
current->rt.time slice = (int)rt;
最後に，ユーザが指定した優先度と SCHED FIFO を
ことでカーネルモジュールを操作できるように設計す
引数として，Linux カーネルの sched setscheduler 関
る．Resch モジュールのインストール時に write シス
数を実行すれば，タスクは RMCL によってスケジュー
テムコールによって resch write 関数が実行されるよ
リングされるようになる．
期の最後に必ず実行する必要がある．
デバイスとして実装（ /dev/resch ）し，上述した API
の wcet までの残り実行時間を指す．
rt data 構造体は Resch モジュール内で宣言されて
いるため，各タスクに割り当てるためには Linux カー
ネルのタスク構造体（ task struct ）と関連付ける必要
Vol. 0
No. 0
Linux カーネル用リアルタイムスケジューリングモジュール
7
/* t is current time. */
1
0.8
Success ratio
pick next task resch() {
Thp = pick next task rt();
for (each task Ti ) {
if (di − t + ei < ehp &&
dhp − t + ehp ≥ ei )
return Ti ;
0.6
0.4
}
return Thp ;
0
0.7
}
1
リズムを Linux カーネルに簡単に組み込むことを目
0.8
ントが現在のタスクより優先度の高いタスクの周期開
始時もしくは現在のタスクの実行完了時およびスリー
Success ratio
本フレームワークは新規のスケジューリングアルゴ
ライス情報を必要とせず，かつスケジューリングポイ
ルゴ リズムがこれらの制限内で実装可能であるため，
本フレームワークの拡張性は高いと考える．
0.8
0.85
CPU utilization
0.9
0.95
1
0.6
0.4
RM
RMCL
RM-test
RMCL-test
0.2
プ時に限られるアルゴ リズムであれば本フレームワー
クを利用可能である．我々の知る範囲では，多くのア
0.75
図 10 スケジュール成功率（ ui = [0.1, 1.0] ）
Fig. 10 Success ratio (ui = [0.1, 1.0]).
図 9 RMCL アルゴ リズムの疑似コード
Fig. 9 Pseudo code of RMCL algorithm.
的としている．適用範囲としては，Linux のタイムス
RM
RMCL
RM-test
RMCL-test
0.2
0
0.7
0.75
0.8
0.85
CPU utilization
0.9
0.95
1
図 11 スケジュール成功率（ ui = [0.1, 0.5] ）
Fig. 11 Success ratio (ui = [0.1, 0.5]).
4.4 RMCL の実装
を取得する．次に，そのほかのタスク Ti に対して危
5.1.1 シミュレーション環境
RM では CPU 使用率が 69%を超えるとデッド ライ
ンミスを起こす場合があるので，シミュレーションでは
CPU 使用率 70% から 100% までのスケジュール成功
率を評価した．CPU 使用率 U に対して 1, 00000 個の
険状態であるかど うかを調べる．そして，Ti が危険状
タスクセットを作成した．タスクの周期 pi は 1 ∼ 30ms
本節では ，RMCL の pick next task resch 関数に
おけ る実装を述べる．図 9 にその実装の疑似コー
ド を示す．まず，Linux カーネルに実装されている
pick next task rt 関数を呼んで最高優先度タスク Thp
態であり，かつ Ti に最高優先度を与えた場合に Thp
を想定して [100, 3000] の範囲で無作為に決定した．固
が危険状態にならなければ Ti を選択する．もし，危
定優先度アルゴ リズムの性能が個々の CPU 使用率や
険状態であるタスクが存在しなければ単純に最高優先
タスク数に依存するため，個々のタスクの CPU 使用
度タスクである Thp を選択する．
率 ui は [0.1, 1.0] の範囲と [0.1, 0.5] の範囲で一様分
5. 評
価
本章では，提案アルゴ リズムである RMCL の理論
的な性能評価と Resch モジュールを組み込んだリア
布によって決定する 2 通りを評価した．タスク Ti の
実行時間は ci = ui pi で算出できる．
5.1.2 シミュレーション結果
図 10 は個々のタスクの CPU 使用率が 0.1 ∼ 1.0
ルタイム Linux の実環境における性能評価を行う．
の場合のスケジュール成功率を示している． RM と
5.1 シミュレーションによる評価
シミュレーションにより多様なタスクセットに対す
る RMCL アルゴ リズムと従来の RM アルゴ リズムの
スケジュール成功率（ Success Ratio ）☆ を計測し，リ
RMCL は与えられたタスクセットを実際にスケジュー
リングした場合のスケジュール成功率であり，RM-test
と RMCL-test は RTA を用いたスケジュール可能性
判定でアド ミッションコントロールした場合のスケ
アルタイム性を保証可能な CPU 使用率を評価した．
ジュール成功率である．
まず，文献 1) でも報告があるように RM の RTA
☆
Success Ratio =
# of successfully scheduled task sets
# of scheduled task sets
は非常に厳密であるため RM と RM-test に差は見ら
8
情報処理学会論文誌
1959
れなかった．一方，3.2 節で述べた RMCL の RTA で
を搭載し，主記憶 2GB の PC を使用した．本論文で
は，2 つ以上のタスクが危険状態になる条件を満たし
はシングルコアを対象としたスケジューリングアルゴ
た場合にスケジュール不可能と判定し，危険状態にな
リズムを提案しているので，Linux は CPU の 1 コア
るタイミングによってはスケジュール可能であるタス
のみを使う設定でコンパイルを行った．
クセットもスケジュール不可能と判定してしまう場合
まず，画像処理用ライブラリである OpenCV5) を
があるため，実際のスケジューリングによる結果とス
使用して特徴点を抽出して画像認識を行うプログラ
ケジュール可能性判定による結果に差が見られた．こ
ムを作成し，各タスクに入力する画像サイズや画像処
の差を縮めることは今後の課題とする．
理の周期を調節することで CPU 使用率が {0.85, 0.9,
上述したように RMCL のスケジュール可能性判定
0.95, 1.0} となる状態を作り出してデッド ラインミス
は厳密ではないが，それでも RM に比べて 10%程度高
率を計測する実験を行った．5.1.2 節のシミュレーショ
い CPU 使用率でもスケジュール成功率を 100%に維
ンによる評価結果より RM と RMCL でデッド ライン
持できた．実際にタスクセットを RMCL スケジューリ
ミスが発生するのは CPU 使用率が 85%以上の場合な
ングした場合は，さらに 2∼5%程度スケジュール成功
ので，CPU 使用率が 80%以下の実験は省略した．
率が高く，CPU 使用率が 95%の段階でもスケジュー
OpenCV による画像処理実験では同一タスクに対
ル成功率は 98.5%であり，最適な EDF に匹敵する性
する入力画像のサイズが変わらないので，各周期での
能を発揮できたことがわかる．
実行時間は比較的一定であった．しかしながら，マル
図 11 は個々のタスクの CPU 使用率が 0.1 ∼ 0.5 の
チメディア処理ではしばしば各周期で実行時間が大き
場合のスケジュール成功率を示している．図 10 の結
く変動することが知られている．そこで，FFmpeg4)
果と同様に，RM では実際のスケジューリングと理論
を使用して MPEG4 デコードプログラムを作成し，各
的なスケジュール可能性判定による差は見られなかっ
タスクに入力する動画のフレームレートを調節するこ
たが，RMCL では図 10 の結果よりも大きな差が見ら
とで CPU 使用率が平均的に {0.85, 0.9, 0.95, 1.0} と
れた．これは個々の CPU 使用率が 0.1 ∼ 0.5 となっ
なる状態を作り出してデッド ラインミス率を計測する
たことで，全体的にタスクセットのタスク数が増え，
実験も行った．OpenCV を使用して MPEG4 ファイ
実際にはスケジュール可能であるタスクをスケジュー
ルを作成することでフレームレートを調節した．
ル不可能であると判定しまう確率が高くなったためで
CPU 使用率でスケジュール成功率を 100%に保つこ
とができた．実際に RMCL によってスケジューリン
グした場合は，さらに 5% 高い CPU 使用率 90%でも
固定優先度アルゴ リズムの性能が個々のタスクの
CPU 使用率やタスク数に依存することを考慮して，
それぞれの実験においてタスク数が 4 つの場合と 8 つ
の場合で評価を行った．また，CPU 使用率はおおよ
その値で算出しており，実際の CPU 使用率よりも少
スケジュール成功率を 100%に保つことができた．
し大きめに見積もった．
あると考えられる．それでも RM より 5% 程度高い
これらの結果から，理論的に RM より RMCL のほ
うが高い CPU 使用率でリアルタイム性を保証可能で
5.2.2 OpenCV による実験結果
表 1 は OpenCV を使って 4 つの画像処理タスク
あり，実際にスケジューリングした場合も RM より
T1 ∼ T4 を実行した場合の Native と T-ReX におけ
RMCL のほうが高い CPU 使用率でリアルタイム性
るデッド ラインミス率を示している．周期の長さは
を維持可能であることがわかった．
5.2 実機による評価
実機上での画像処理による実験で Resch モジュー
ルを組み込んだ Linux とネイティブの Linux のデッ
T1 < T2 < T3 < T4 とした．紙面の都合上，Native
か T-ReX かのど ちらかでデッド ラインミスを発生し
たタスクの結果のみ示す．CPU 使用率が 85%の場合，
Native と T-ReX の両方ともデッド ラインミスなし
ド ラインミス率を計測し ，高負荷状態におけるリア
に全タスクを実行することができた．しかしながら，
ルタイム性を評価した．Resch モジュールを組み込
CPU 使用率が 90%以上になると，RM によってスケ
んだ Linux を T-ReX（ The Real-time eXtension の
ジューリングを行う Native ではデッドラインミスが増
略）と表記し，ネイティブの Linux を Native と表記
加し，最終的に CPU 使用率が 100%になると最低優先
する．スケジューリングアルゴ リズムとして，T-ReX
度タスクである T4 のデッド ラインミス率は 99.9%に
は RMCL を採用し，Native は RM を採用する．
5.2.1 実 験 環 境
評価には Intel Core2 Duo CPU E6750 2.66GHz
達し，ほとんど適切に処理が行い状況になってしまっ
た．一方，RMCL によってスケジューリングを行う
T-ReX では，CPU 使用率が 95%に達してもデッドラ
Vol. 0
No. 0
Linux カーネル用リアルタイムスケジューリングモジュール
9
表 1 デッド ラインミス率（ OpenCV，タスク数 4 ）
Table 1 Deadline miss ratio (OpenCV, four tasks)
タスク
T3
T4
U = 0.85
Native
T-ReX
0%
0%
0%
0%
U = 0.9
Native
T-ReX
0%
0%
9.5%
0%
U = 0.95
Native
T-ReX
0%
0%
18.9%
0%
U = 1.0
Native
T-ReX
7.31%
0%
99.9%
19.3%
表 2 デッド ラインミス率（ OpenCV，タスク数 8 ）
Table 2 Deadline miss ratio (OpenCV, eight tasks)
タスク
T6
T7
T8
U = 0.85
Native
T-ReX
0%
0%
0%
0%
0%
0%
U = 0.9
Native
T-ReX
0%
0%
0%
0%
0%
0%
インミスは発生せず，CPU 使用率が 100%になっても
U = 0.95
Native
T-ReX
2.79%
0%
7.80%
0%
10.4%
0%
U = 1.0
Native
T-ReX
9.21%
0%
40.1%
0%
99.9%
28.5%
実行時間を基にして残り実行時間を算出すると実際の
最低優先度タスク T4 のデッドラインミス率は 19.3%に
残り実行時間と大きな誤差がでてしまう．そこで，残
抑えることができた．
り時間の算出に最悪実行時間を使うものとそれまでの
表 2 は OpenCV を使って 8 つの画像処理タスク
T1 ∼ T8 を実行した場合の Native と T-ReX におけ
るデッド ラインミス率を示している．この実験では
平均実行時間を使うものの 2 通りを用意した．前者を
T-ReX(W)，後者を T-ReX(A) と表記する．
表 3 と表 4 は FFmpeg を使って，それぞれ 4 つの
CPU 使用率が 90%になっても Native と T-ReX の
両方ともデッド ラインミスを起こさなかった．タスク
数が 8 つに増えたことで個々のタスクの CPU 使用
率は比較的小さくなり，その分すべてのタスクがリア
ルタイム性を維持できる CPU 使用率が上がったのだ
MPEG4 デコード タスク T1 ∼ T4 と 8 つの MPEG4
デコード タスク T1 ∼ T7 を実行した場合の Native
と T-ReX におけるデッド ラインミス率を示している．
デッド ラインミスが発生する傾向は先の OpenCV に
よる実験とほとんど 同じであった．T-ReX(W) と T-
と考えられる．しかしながら，CPU 使用率が 95%に
ReX(A) を比べると最悪実行時間を基に残り実行時間
なると Native では 3 つの低優先度タスクがデッド ラ
を算出して Critical Laxity を扱うほうがデッド ライ
インミスを起こしてしまった．さらに CPU 使用率が
ンミス率が小さかった．このことから，最悪実行時間
100%になると，デッド ラインミス率は T7 では 40%，
T8 では 99.9%も検出され，リアルタイム性が劇的に
を基にして残り実行時間を算出することで，実際には
低下してしまった．先の実験に比べて個々の CPU 使
しまっても大きなリアルタイム性の低下を招くことは
用率は小さくてもタスク数が多いので，一度リアルタ
ないことがわかった．一方，平均実行時間を基にして
イム性が保てなくなるとデッド ラインミス率の増加量
残り実行時間を算出すると，実際には Critical Laxity
危険状態になっていないタスクに最高優先度を与えて
が大きくなったのだと考えられる．一方，T-ReX では
状態になっているタスクを検出できず，結果としてリ
CPU 使用率が 90%に達してもデッド ラインミスは検
アルタイム性が低下してしまったのだと考えられる．
出されず，CPU 使用率が 100%の状態でも T6 と T7
これらの結果から，Resch モジュールを組み込こん
にはデッド ラインミスは検出されず T8 のデッド ライ
だ T-ReX は実行時間の変動が大きいリアルタイム処
ンミス率も 28.5%に抑えることができた．
理に対しても有効であり，Critical Laxity の検出には
これらの結果から，個々のタスクの CPU 使用率や
タスク数に依存せず，Native よりも T-ReX のほうが
高い CPU 使用率でリアルタイム性を維持できること
がわかった．
最悪実行時間を用いたほうが高いリアルタイム性を実
現できることがわかった．
6. 結
論
5.2.3 FFmpeg による実験結果
OpenCV による画像処理とは異なり，MPEG4 デ
善するための Resch モジュールを開発した．具体的
コード は各タスクの実行時間に変動が見られた．T-
には，固定優先度アルゴ リズムの利点を継承しながら
ReX において Critical Laxity を検出するためには各
タスクの残り実行時間を算出する必要があるが，最悪
も高負荷状態において十分なリアルタイム性を提供
本論文では，Linux カーネルのリアルタイム性を改
可能な RMCL スケジューリングアルゴ リズムを提案
10
1959
情報処理学会論文誌
表 3 デッド ラインミス率（ FFmpeg，タスク数 4 ）
Table 3 Deadline miss ratio (FFmpeg, four tasks)
タスク
T2
T3
T4
Native
0%
0%
0.3%
U = 0.85
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0%
Native
0%
0.1%
8.20%
U = 0.9%
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0.01%
Native
0%
0%
19.3%
U = 0.95
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0.09%
Native
0%
7.81%
94.8%
U = 1.0
T-ReX(W, A)
0.01%, 0.02%
0.08%, 1.42%
1.97%, 3.69%
Native
0%
2.23%
39.1%
91.3%
U = 1.0
T-ReX(W, A)
0%, 0.01%
0.02%, 0.09%
0.07%, 2.13%
1.36%, 3.07%
表 4 デッド ラインミス率（ FFmpeg，タスク数 8 ）
Table 4 Deadline miss ratio (FFmpeg, eight tasks)
タスク
T5
T6
T7
T8
Native
0%
0%
0%
0%
U = 0.85
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0%
0%, 0%
Native
0%
0%
0.1%
0%
U = 0.9
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0%
0%, 0%
し，そのスケジューリング解析を行った．また，Linux
カーネルに必要最小限の修正を加えるだけで新規のス
ケジューリングアルゴ リズムを組み込むことができる
フレームワークの設計と実装を行った．
シミュレーションによる評価では，提案アルゴ リズ
ムである RMCL が従来の固定優先度アルゴ リズム
である RM よりも約 10∼15%高い CPU 使用率でリ
アルタイム性を保証可能であることを示した．また，
OpenCV と FFmpeg を使った実機による評価では，
ネイティブな Linux に比べて，Resch モジュールを組
み込んだ Linux T-ReX が高負荷状態における低優先
度タスクのデッドラインミス率を約 70∼90%削減でき
ることを実証した．
今後は本論文で開発した Resch モジュールを土台
として，マルチコアへの対応を考える．本論文で提案
した RMCL は，もともとマルチプロセッサ向けに提
案された Zero Laxity による最高優先度割当てを応用
したアルゴ リズムなので，マルチコアでも高い性能を
発揮すると予想できる．また，RMCL のスケジュー
ル可能性判定には改善の余地があるため，今後はさら
に厳密なスケジューリング解析を考える．さらには，
電圧周波数制御による省電力化や特定のタスクに対し
てリアルタイム性を確保できる資源予約等，次世代の
組み込みシステムに必要とされる機能を提供できるモ
ジュールを開発していく予定である．
謝辞 本研究は，JST CREST の支援による．また，
本研究の一部は，日本学術振興会の支援による．
参
考 文
献
1) Audsley, N., Burns, A., Richardson, M., Tindell, K. and Wellings, A.: Applying New
Native
0%
0%
2.22%
2.93%
U = 0.95
T-ReX(W, A)
0%, 0%
0%, 0%
0%, 0%
0%, 0.01%
Scheduling Theory to Static Priority Preemptive Scheduling, Software Engineering Journal ,
Vol.8, No.5, pp.285–292 (1993).
2) Buttazzo, G.: Rate Monotonic vs. EDF: Judgment Day, Real-Time Systems, Vol.29, pp.5–26
(2005).
3) Cho, S., Lee, S., Han, A. and Lin, K.: Efficient Real-Time Scheduling Algorithms for
Multiprocessor Systems, IEICE Transactions
on Communications, Vol. E85-B, No. 12, pp.
2859–2867 (2002).
4) FFmpeg Project: FFmpeg, http://ffmpeg.
mplayerhq.hu/.
5) Intel Corporation: OpenCV, http://www.intel.
com/technology/computing/opencv/index.htm.
6) Liu, C. and Layland, J.: Scheduling Algorithms for Multiprogramming in a Hard
Real-Time Environment, Journal of the ACM ,
Vol.20, No.1, pp.46–61 (1973).
7) Oikawa, S. and Rajkumar, R.: Portable RT: A
Portable Resource Kernel for Guaranteed and
Enforced Timing Behavior, Proceedings of the
5th IEEE Real-Time Technology and Aplications Symposium (1999).
8) Rajkumar, R., Lee, C., Lehoczky, J. and
Siewiorek, D.: A QoS-based Resource Allocation Model, Proceedings of the 18th IEEE RealTime Systems Symposium (1997).
9) TimeSys Corporation: TimeSys Linux, http://
www.timesys.com/.
10) Yodaiken, V.: The RTLinux Manifesto, Proceedings of the 5th Linux Expo (1999).
11) 石綿陽一, 松井俊浩, 國吉康: 高度な実時間処理
機能を持つ Linux の開発, 第 16 回日本ロボット
学会学術講演会予稿集, pp.355–356 (1998).