JP2008527558A - タスクスケジューリングのデータ処理システム及び方法 - Google Patents

Abstract

マルチタスク環境におけるデータ処理システムが提供される。前記データ処理システムは、複数のタスクのインターリーブ処理に対して少なくとも１つの処理ユニット１を有する。前記複数のタスクの各々は、関連付けられた利用可能なデータ及び対応する待機時間を有する。加えて、前記複数のタスクを前記少なくとも１つの処理ユニット１により処理されるようにスケジューリングするタスクスケジューラ２が提供される。タスクスケジューリングは、前記複数のタスクの１つに利用可能なデータの量に基づいて、及び当該タスクにより処理されるデータの待機時間に基づいて実行される。

Description

本発明は、マルチタスク環境（multi-tasking environment）におけるデータ処理システム及びマルチタスクデータ処理環境内でタスクスケジューリング（task scheduling）する方法に関する。

新しい種類のマルチプロセッサ又はマルチコアシステムの性能を向上するために、複数のタスクが、オペレーティングシステムにより、実質的に同時に又はタスクスケジューリングにより複数のタスク間で切り換えることによりインターリーブされた形で実行される。タスクスケジューリング技術は、ラウンドロビン（Round Robin）、ＲＭＡのような優先順位ベース又はＥＤＦのような期限ベースのアルゴリズムを含みうる。ラウンドロビン形式に基づくタスクスケジューリングにおいて、実行可能なタスクは、ラウンドロビン技術で確認され、プロセッサ又は処理ユニットで処理されるべきタスクが選択される。優先順位ベースのタスクスケジューリングにおいて、処理ユニットで実行されるべき次のタスクのスケジューリングは、静的又は動的のいずれかで決定されたタスクの各々の優先順位に基づく。タスクの選択は、それぞれ、ＲＭＡのように静的に、タスクの頻度、即ち毎秒の回数に基づくＥＤＦのように動的に、又は期限、即ち残っているサイクルに基づいて実行される。ＥＤＦは、最良のスケジューリングアルゴリズムと見なされることができるが、しかしながら、残っているサイクルを決定する複雑さのため、ランタイムに及びオンザフライ（on the fly）でタスクスケジューリングを実行することができない。したがって、ＥＤＦ技術は、実際の埋め込まれたシステムにおいて好ましくなかった。ＲＭＡのように静的な優先順位を決定するためのタスクの頻度の使用は、単純であるが、非常に強力かつ効果的なタスクスケジューリング技術である。処理に対する動的なデータ出現（data appearance）が規則的でなく不規則である場合、タスクの頻度に基づく技術は、特にデータ依存性の高いタスクに対して効率的なスケジューリングを実行することができない。

既存のスケジューリング技術の場合、データ出現の不規則性は、不要の高価なコンテキスト切り換え（context switch）並びにキャッシュ破損、キャッシュミス及び過剰なバストラフィックのような関連した性能副産物をもたらす可能性がある。

静的優先順位スケジューリング方式の場合、タスク切り換えは、準備ができているが、処理するのにかなりの時間を要するデータより少ないデータを持つタスクに対して実行されることができ、この結果、コンテキスト切り換えはすぐに実行される。

本発明の目的は、データ出現不規則性を効果的に処理する改良されたタスクスケジューリングを持つデータ処理システムを提供することである。

この目的は、請求項１によるデータ処理システムにより、及び請求項４によるデータ処理システム内でタスクスケジューリングする方法により解決される。

したがって、マルチタスク環境におけるデータ処理システムが提供される。前記データ処理システムは、複数のタスクのインターリーブ処理（interleaved processing）に対する少なくとも１つの処理ユニットを有する。前記複数のタスクの各々は、関連付けられた利用可能なデータ及び対応する待機時間を有する。加えて、タスクスケジューラは、前記複数のタスクを前記少なくとも１つの処理ユニットにより処理されるようにスケジューリングするために提供される。タスクスケジューリングは、前記複数のタスクの１つに利用可能なデータ量に基づいて、及び当該タスクにより処理されるデータの待機時間に基づいて実行される。

したがって、前記タスクのいずれか１つが飢餓状態（starved）になる、即ちスケジュールされないことは避けられることができる。前記タスクスケジューリングはデータの量及び前記データの待機時間に基づくので、両方のパラメータが前記タスクスケジューリングに影響する。

本発明の一態様によると、前記タスクスケジューラは、タスクにより処理されるべき前記データの量及び前記データの待機時間に基づいて前記複数のタスクのスケジューリングを実行する。したがって、前記データの量と前記待機時間との間のトレードオフは、小さな待機時間に対する大量のデータでさえ、それぞれのタスクスケジューリングの確率を増大し、他方で、少量のデータに対する長い待機時間でさえも、タスクスケジューリングの確率を増大するように、実行されることができる。

本発明は、マルチタスクデータ処理環境内でタスクスケジューリングする方法にも関する。処理される準備ができている全てのタスクが識別され、前記複数のタスクの各々は、関連付けられた利用可能なデータ及び対応する待機時間を有する。前記処理される準備ができているタスクの各々に関連付けられた利用可能なデータの量及びこのデータの待機時間が決定される。前記タスクは、利用可能なデータの量及びこのデータの待機時間によって切り換えられる。

本発明の更に他の態様によると、タスクのデータを書き込むのに利用可能なスペースの量及びこのデータの待機時間も、前記タスクスケジューリングに影響する。

本発明のこれら及び他の態様は、以下に記載される実施例を参照して及び以下の図面に関して説明され、明らかになる。

図１は、マルチタスク環境におけるデータ処理システムを示す。前記データ処理システムは、少なくとも１つの処理ユニット１と、タスクスケジューラ２と、キャッシュ３と、バス４と、メインメモリ５とを有する。処理ユニット１は、タスクスケジューラ２及びキャッシュ３を介してバス４に接続される。メインメモリ５もバス４に接続されることができる。１つの処理ユニット１のみが図１に明示的に示されているが、他の処理ユニットも、図１による前記データ処理システムに含まれることができる。

好ましくは、図１による前記データ処理システムは、アプリケーションをストリーミングするように設計される。幾つかのタスク又は複数のタスクは、インターリーブ処理により前記処理ユニットの効率を向上するために処理ユニット１上にマッピングされる。複数のタスクがデータ処理ユニット１により処理されることになるので、前記タスクの一部が、キャッシュ３又はメモリ５内のデータ利用可能性を依然として待機することになる可能性がある一方で、他のタスクが既にデータを中に有し、この結果、処理ユニット１は、前記データの処理を直ちに開始することができる。処理するデータを有するこのようなタスクは、実行可能タスク（ready tasks）と称されることができる。処理されるべきデータを依然として待機しているタスクは、ブロックタスク（blocked tasks）と称されることができる。したがって、前記実行可能タスクの幾つかは、これらのデータが例えばキャッシュ３又はメモリ５において既に利用可能である場合に処理ユニット１による実行を待機していることができる。

本発明によると、前記実行可能タスクの１つをスケジューリングするためにデータの量及びこのデータに関連する待機時間を考慮に入れる動的スケジューリングアルゴリズムが提供される。バイト単位の利用可能なデータサイズとサイクル単位のこのデータの現在の待機時間との積は、データモーメント（data momentum）と称されることができる。

例えば、第１のタスクT₁は、データd₁が処理ユニット１による処理に利用可能である場合に実行可能タスクになる。前記タスクが出力に書き込む十分なスペースを持つことが仮定される。t₁サイクル後、データd₂も処理に利用可能になる。t₂サイクルの終わりに（t₂＞t₁）、前記データと前記データの待機時間との積は、M₁(t)=d₁*t₂+d₂*(t₂-t₁)として定義される。このような積は、バイト‐サイクル単位のデータモーメントと称される。これは、全ての実行可能タスクに対して計算されることができる。

更に、処理ユニットPU₁上にマッピングされるタスクT₁、T₄及びT₆を検討し、タスクT₁及びタスクT₆は実行可能タスクを構成し、タスクT₄はブロックタスクを構成する。前記積又はデータモーメントM₁(t)及びM₆(t)が、実行可能タスクT₁及びT₆に対して計算される。この場合、２つのタスクT₁及びT₆のいずれがより高い積又はデータモーメントを有するかが決定され、このタスクは、次に、即ち次の実行タスク（running task）として処理されるようにスケジューリングされる。前記積又はデータモーメントは、少なくとも増大されるデータ待機時間のために前記タスクが最終的にスケジューリングされるまでサイクルごとに増大する。前記タスクが前記処理ユニットにより処理されるようにスケジューリングされるとすぐに、前記タスクのデータは、前記処理ユニット上の処理のために消費され、この結果、前記タスクの積又はデータモーメントは減少し始め、この結果、前記タスクは、実行可能リストからより高いモーメントを持つ他の実行可能タスクにより置換されることさえできる。

実際のタスクスケジューリングは、２つの形によって、即ちスケジュールアウトする（sheduling out）又はスケジュールインする（scheduling in）ことにより実行されることができる。実行可能タスクがスケジュールインされる、即ち実行タスクとして選択される場合、前記実行可能タスクの中で最も高いデータモーメント又は積を有するタスクが選択される。スケジュールアウトストラテジが実行される場合、現在実行中のタスクは、このタスクのデータモーメントが残りの実行可能タスクのいずれかのデータモーメントの所定のパーセンテージより小さくなる場合に置換される。典型的な数は５０％である。しかしながら、他の数も選択されることができる。

データのD個のブロックd₁, d₂, ...d_Dを持つ実行可能タスクTのデータモーメントM_T(t)は、
M_T(t)=d₁*(t-t_d1)+d₂*(t-t_d2)+...+d_D*(t-t_dD) （１）
のように時間tの関数として計算されることができ、ここで前記データブロックは、時刻t_d1, t_d2, ..., t_dDに到着する。したがって、前記データモーメントは、

のように計算されることもできる。

図２は、第１の実施例によるタスクスケジューリングのフローチャートを示す。ステップ１において、全ての実行可能タスクが識別され、リストされる。ステップ２において、式（１）又は（２）によって前記データモーメントが、前記実行可能タスクの各々に対して、及び実行タスク、即ち前記処理ユニットにより現在処理されているタスクに対して計算される。ステップ３において、前記実行タスクのデータモーメントが前記リストされた実行可能タスクの最高のデータモーメントの固定パーセンテージ、例えば５０％より大きいかどうかが決定される。これが真（true）である場合、前記実行タスクはステップ４において実行され、フローはステップ１に進む。ステップ５において、前記実際に実行中のタスクはスケジュールアウトされ、最高のデータモーメントを有する前記実行可能タスクの１つが前記処理ユニットにより処理されるようにスケジューリングされる。この後に、前記フローはステップ１に進む。

好ましくは前記第１の実施例に基づく第２の実施例によると、前記出力を買い込むスペースの利用可能性が、前記式（１）又は（２）に追加されることもできる。したがって、２つのタスクがおおよそ同じ量のデータモーメントを持つ場合、スペースの実際の利用可能性が、前記２つのタスクを差別化するのに使用されることができる。より多くのスペースモーメント（space momentum）、即ちより長い時間に対してデータを書き込む、より多くのスペースを持つタスクが、より少ないスペースモーメントを持つタスクより好ましい。

書き込むスペースのD個のブロック、例えばs₁, s₂, ..., s_Dを持つ実行可能タスクTのスペースモーメントは、
M_T(t)=s₁*(t-t_s1)+s₂*(t-t_s2)+...+s_D*(t-s_dD) （３）
のように時間tの関数として計算されることができ、ここで前記データブロックを書き込むスペースは時刻t_s1, t_s2, ..., t_sDに出現する。したがって、前記スペースモーメントは、

のように計算されることもできる。

前記スペースが前記出力を書き込むタスクに利用可能ではないが、前記データモーメントが前記実行可能タスク中で最高である場合、前記コンテキスト切り換えが直ちに生じるので、前記タスクのスケジューリングは役に立たず、この結果、データモーメントベースのタスクスケジューリングの目的は廃止（obsolete）にされる。したがって、総合的モーメントが、前記タスクの各々に対して定義され、前記データモーメント及びスペースモーメントに対するPRODUCT又はMIN演算として定義されることができる。

本発明の他の実施例において、前記タスクの前記総合的モーメントが、前記複数のタスクをスケジューリングするパラメータとして使用されることができる。

したがって、前記総合的モーメントは、

のように計算されることができる。

前記タスクスケジューラは、前記実行可能タスク中の最高の総合的モーメントを持つタスクを、前記処理ユニットにより処理されるように選択する。前記実行タスクの総合的モーメントが前記実行可能リスト中の残りのタスクの最高の総合的モーメントの例えば０．５倍より小さい場合に、スケジュールアウトが実行される。

代わりに又は加えて、前記タスクスケジューリングは、上述のスペースモーメントに基づいて実行されることもできる。

上述のデータ処理システムは、ストリーミングオーディオ／ビデオアプリケーションを処理するマルチプロセスアーキテクチャを構成する。本発明の上述の原理は、次世代TriMedia又は他のメディアプロセッサにおいて実施されることができる。

上述の実施例が、本発明を限定するのではなく説明し、当業者が、添付の請求項の範囲から逸脱することなく多くの代替実施例を設計することができることに注意すべきである。請求項において、括弧間に配置された参照符号は、前記請求項を限定するように解釈されるべきでない。単語"有する"は、請求項に記載された要素又はステップ以外の要素又はステップの存在を除外しない。要素に先行する単語"１つの"は、複数のこのような要素の存在を除外しない。複数の手段を列挙する装置請求項において、これらの手段の幾つかがハードウェアの同一アイテムにより実施されることができる。特定の方策が相互に異なる従属請求項内にあるという単なる事実は、これらの方策の組み合わせが有利に使用されることができないことを示さない。

更に、請求項内の参照符号は、前記請求項の範囲を限定するように構成されるべきでない。

第１の実施例によるデータ処理システムの基本構造のブロック図を示す。 第１の実施例によるタスクスケジューリングのプロセスのフローチャートを示す。

Claims (6)

1. マルチタスク環境におけるデータ処理システムにおいて、
   複数のタスクのインターリーブ処理に対する少なくとも１つの処理ユニットであって、前記複数のタスクの各々が前記複数のタスクの各々に関連付けられた利用可能なデータ及び対応する待機時間を有する、当該少なくとも１つの処理ユニットと、
   特定のタスクに利用可能なデータの量及びタスクの対応する待機時間に基づいて前記少なくとも１つの処理ユニットにより処理されるように前記複数のタスクをスケジューリングするタスクスケジューラと、
   を有するデータ処理システム。
2. 前記タスクスケジューラが、前記複数のタスクの１つの前記利用可能なデータの量と前記待機時間との積に基づいて前記複数のタスクのスケジューリングを実行するように構成される、
   請求項１に記載のデータ処理システム。
3. 前記タスクスケジューラが、前記複数のタスクの１つの前記利用可能なデータのデータブロックと前記データブロックに関連付けられた待機時間との積の和に基づいて前記複数のタスクのスケジューリングを実行するように構成される、
   請求項１又は２に記載のデータ処理システム。
4. マルチタスクデータ処理システム内でタスクスケジューリングする方法において、
   処理される準備ができている全てのタスクを識別するステップであって、前記複数のタスクの各々が、前記タスクの各々に関連付けられた利用可能なデータ及び対応する待機時間を有する、当該識別するステップと、
   前記処理される準備ができているタスクの各々に関連付けられた利用可能なデータの量及び前記処理される準備ができているタスクの各々に対して前記データを待機する時間を決定するステップと、
   前記処理される準備ができているタスクの前記利用可能なデータの量及び前記データの待機時間によりタスクスケジューリングするステップと、
   を有するタスクスケジューリングする方法。
5. 現在処理されているタスクの利用可能なデータの量及び対応する待機時間を決定するステップと、
   これらの結果を前記処理される準備ができているタスクの各々に関連付けられた前記利用可能なデータの量及び前記対応する待機時間と比較するステップと、
   前記利用可能なデータの量及び前記関連付けられた待機時間が、前記処理される準備ができているタスクの前記利用可能なデータの量及び前記対応する待機時間の所定のパーセンテージより低い場合に前記現在処理されているタスクをスケジュールアウトするステップと、
   を有する、請求項４に記載のタスクスケジューリングする方法。
6. 前記処理される準備ができているタスクの各々に関連付けられたデータを書き込むのに利用可能なスペースの量及び前記処理される準備ができているタスクの各々に対して書き込まれるべきデータに対する待機時間を決定するステップ、
   を更に有し、
   タスク切り換えが、前記データを書き込むのに利用可能なスペースの量及び前記書き込まれるべきデータの待機時間に基づく、
   請求項４又は５に記載のタスクスケジューリングする方法。

Images