JP2005517228A - スケジューリングの順序付けられたステージの基準を使用してリクエストをスケジューリングする方法及び装置 - Google Patents

Abstract

本発明は、複数のイニシエータデバイスから１つのリソースへのリクエストのスケジューリングを提供する。或る実施例では、スレッド内のリクエストのスケジューリング（２２０）及びイニシエータデバイスのアクセスのスケージュリングがＱＯＳを保証しながら（２１５）実行される。

Description

【０００１】
【技術分野】
ここに述べるメカニズムは、多数の独立したイニシエータがダイナミックランダムアクセスメモリ（ＤＲＡＭ）のサブシステムを共用するシステムに適用される。
【０００２】
【背景技術】
単一チップに形成されたシステムでは、多数の独立したイニシエータ（マイクロプロセッサ、信号プロセッサ等）が、コスト、ボード面積及び電力の理由で、これらイニシエータ間に共用されたダイナミックランダムアクセスメモリ（ＤＲＡＭ）サブシステムにアクセスすることは、珍しいことではない。このシステムは、イニシエータの各々に異なるサービスクオリティ（ＱＯＳ）が与えられることを必要とする。第２に、イニシエータに提示されるメモリ順序付けモデルも重要となる。理想的には、イニシエータは、できるだけ強力に順序付けされたメモリモデルを使用することを希望する。同時に、ＤＲＡＭ要求がＤＲＡＭサブシステムに提示される順序は、ＤＲＡＭ性能に対して著しい影響を及ぼし得る。スレッドＱＯＳ又はＤＲＡＭ効率の理由で要求を更に再順序付けすると、強力に順序付けされたメモリモデルを妥協させることができる。強力に順序付けされたメモリモデルを提示し、異なるイニシエータに異なるサービスクオリティを与え、そしてＤＲＡＭ効率をできるだけ高く保持する独特のＤＲＡＭスケジューリングメカニズムが要求される。
【０００３】
各異なるイニシエータからの要求ストリームは、スレッドとして説明することができる。ＤＲＡＭスケジューラーが同じスレッドからの要求を再順序付けしない場合には、スレッド内の要求順序が維持され、そして全体的なＤＲＡＭ要求順序は、単に、スレッド当たりの逐次の要求ストリームをインターリーブしたものとなる。これは、「逐次一貫性」、即ち多数のイニシエータコンポーネントを含むシステムに使用可能な最も強いメモリ順序付けモデルの定義である。（逐次一貫性の更なる説明については、Ｌ．ランポート氏の「How to Make a Multi-processing Computer That Correctly Executes Multi-process Programs」、ＩＥＥＥトランザクション・オン・コンピュータズ、Ｃ−２８（９）：２４１−２４８，１９７９年９月、を参照されたい。）
【０００４】
既存のシステムは、ＤＲＡＭ効率のスケジューリングが生じる（もし行われれば）場所以外のシステム内のポイントで要求を順序付けし、及び／又はそれらシステムは、処理スレッド内で要求を再順序付けする。例えば、要求は、イニシエータから標準的なコンピュータバスを経てＤＲＡＭコントローラへ搬送される。要求の順序（スレッド間及びスレッド内）は、コンピュータバスへアクセスするときに確立され、ＤＲＡＭコントローラによる変更は許されない。この場合に、効率に対するＤＲＡＭのスケジューリングは、低いＤＲＡＭ効率を生じるに必要なもの以上の制約を受ける。異なる例では、各イニシエータは、ＤＲＡＭコントローラとのそれ自身の個々のインターフェイスを有し、ＤＲＡＭコントローラがスレッドの順序を維持しながら要求をスケジューリングするのを許す。この種のシステムは、潜在的に満足な結果を達成するが、ＤＲＡＭコントローラへの配線を浪費する。このようなシステムでは、スレッド内でＤＲＡＭ要求を再順序付けすることができる。これは、高いＤＲＡＭ効率を生じるが、メモリモデルを著しく緩和し、即ち逐次一貫性のメモリモデルをもはや提示しない。従って、強力なメモリモデルを保持すると同時に、メモリ要求の再順序付けを許して、高いＤＲＡＭ効率及びＱＯＳ保証を達成することが重要である。
【０００５】
【発明の開示】
本発明は、複数のイニシエータからＤＲＡＭサブシステムのような１つのリソースへの要求をスケジューリングすることに関する。各イニシエータスレッドには、異なるサービスクオリティが与えられる一方、リソース利用度が高く保持され、そして強力な順序付けモデルが維持される。
【０００６】
【発明を実施するための最良の形態】
ここに説明するメカニズムは、多数の独立したイニシエータがダイナミックランダムアクセスメモリ（ＤＲＡＭ）サブシステムを共用するシステムに適用される。
【０００７】
１つの実施形態において、本発明は、異なるイニシエータに、互いに独立した所定のサービスクオリティを与えると同時に、ＤＲＡＭの効率をできるだけ高く保持し、そして強いメモリ順序付けモデルをイニシエータに提示できるようにする。
【０００８】
図１は、ＤＲＡＭスケジューリングシステムの一実施形態を示す高レベルブロック図である。異なるイニシエータからの要求１０は、マルチスレッドのインターフェイス１５を経て到着する。イニシエータは、デバイス又はプロセスとして実施される。異なるイニシエータからの要求１０は、インターフェイスにおいて異なるスレッド識別子（「スレッドＩＤ」）で識別された異なるスレッドを横切って通信される。これは、要求をスレッド（又はイニシエータ）により、スレッドごとの要求待ち行列、例えば、２０、２５、３０に分割できるようにする。これらスレッド待ち行列２０、２５、３０からの要求は、ＤＲＡＭ及びスレッドスケジューラーブロック３５へ並列に提示される。このスケジューラーブロック３５は、要求がＤＲＡＭコントローラ４０へ提示される順序を決定し、ＤＲＡＭコントローラは、次いで、実際のＤＲＡＭサブシステム４５へ要求を送信する役割を果たす。ＤＲＡＭコントローラ４５から応答５０が返送されるときには、それらが、マルチスレッドのインターフェイス１５を経てイニシエータへ返送される。マルチスレッドインターフェイス及びスレッド識別子を使用してイニシエータからの要求の供給を説明した。別の実施形態では、イニシエータごとに個々に単一スレッドインターフェイスが使用される。
【０００９】
ＤＲＡＭ及びスレッドスケジューラー３５は、ＤＲＡＭ要求が処理される順序を確立する同期ポイントとして働く。たとえ要求がマルチスレッドインターフェイスを経てある順序で到着しとしても、それら要求は、スレッドのサービスクオリティ（ＱＯＳ）保証を満足するか又はＤＲＡＭ効率を高めるために、スケジューラーブロック３５により再順序付けすることができる。逆に、ＤＲＡＭコントローラ４０のブロックは、スケジューラーブロック３５により確立される順序が、実際に、要求がコミットされた順序であるように、要求を順次に処理することもできる。しかしながら、スケジューラーブロック３５が、同じスレッドからの要求を再順序付けしない場合には、スレッド内の要求順序が維持され、そして全ＤＲＡＭ要求順序は、単に、スレッドごとの逐次要求ストリームをインターリーブしたものとなる。
【００１０】
図２の簡単なフローチャートを参照して、プロセスの一実施形態を説明する。ステップ２０５において、ＱＯＳ保証に対する好ましい要求順序が識別又は決定される。ＤＲＡＭ効率に対する要求を処理するための好ましい順序は、ステップ２１０で決定される。ステップ２０５及び２１０を実行する際には、メモリ順序付けモデルの制約が考慮に入れられる。好ましいＤＲＡＭ効率順序がＱＯＳ保証を満足する場合には（ステップ２１５）、ＤＲＡＭ効率順序に基づいて要求がスケジュールされる（ステップ２２０）。ＤＲＡＭ効率順序がＱＯＳ保証を満足しない場合には（ステップ２１５）、次に最良のＤＲＡＭ効率順序が決定される（ステップ２２５）。このステップは、ＤＲＡＭ効率順序がＱＯＳ保証を満足するまで繰り返される。
【００１１】
図２に示すプロセスは、１つの実施形態に過ぎない。他の実施形態も意図される。例えば、１つの実施形態では、ＱＯＳ保証を満足する要求順序が決定され、次いで、ＤＲＡＭ効率を最適化するように変更される。
【００１２】
図３は、図１のＤＲＡＭ及びスレッドスケジューラーの一実施形態を詳細に示す。異なるスレッドからの要求３２０、３２５、３３０がＤＲＡＭコントローラ３１０へ順次に送られる。任意の時間に要求が進行するために得るスケジューリングの判断は、スレッドのクオリティサービスのスケジューリング及びＤＲＡＭのスケジューリングの組合せを使用して導出される。
【００１３】
スレッドサービスクオリティスケジューラー３４０は、スレッド状態３５０を保持しそしてそれを使用して、スレッドスケジューリング経過を想起し、そしてどのスレッドを次に進行させるべきか決定する上で助けとする。例えば、スレッドに、ある量のＤＲＡＭ帯域巾が保証される場合には、スレッドスケジューラー３４０は、どのスレッドがどれほどの帯域巾を使用したか追跡し、そしてそれに応じてスレッドをプライオリティ決めする。一方、ＤＲＡＭスケジューラー３４５は、異なるスレッドからの要求をシーケンシングし、ＤＲＡＭ性能を最大にするように試みる。例えば、スケジューラー３４５は、互いに接近した同じＤＲＡＭページにアクセスする要求をスケジューリングして、ＤＲＡＭページヒットを得る機会を増加するように試みることができる。ＤＲＡＭスケジューラー３４５は、ＤＲＡＭにおける状態３５５を使用しそして保持し、そしてその経過にアクセスしてそのスケジューリングを判断する上で助けとなるようにする。
【００１４】
スレッドサービスクオリティスケジューラー３４０及びＤＲＡＭスケジューラー３４５は、異なる振舞いに対して最適化され、そして相反するスケジュールを生じることがある。２つのスケジューラー３４０、３４５の出力は、約束のスレッドサービスクオリティを得る一方、高いＤＲＡＭ効率を得るために、合成される（３６０）か、又は仲裁されねばならない。
【００１５】
ＤＲＡＭスケジューラー３４５は、それ自体、多数の異なるスケジューリング目標のバランスをとらねばならない。１つの実施形態では、スケジューリングコンポーネントは、ここでは絶対的スケジューリング及びコスト関数スケジューリングと称される２つの広いカテゴリーに分類することができる。
【００１６】
絶対的スケジューリングとは、各個々の要求に関して簡単なイエス／ノー判断を行うことのできるスケジューリングを指す。その一例は、ＤＲＡＭバンクスケジューリングである。いかなる所与のＤＲＡＭ要求も、それがアドレスする厳密に１つのバンクを有する。このバンクは、要求を受信するために現在使用できるか、又は他の要求でビジーであってそのときＤＲＡＭへ要求を送信する上で価値がないかのいずれかである。
【００１７】
コスト関数スケジューリングは、各要求に対して直ちにイエス／ノー応答がないという点で更に微妙である。せいぜい、ある時間にＤＲＡＭへ要求を送信すると、高いＤＲＡＭ効率を生じることが多少あると言える。
【００１８】
コスト関数スケジューリングの一例は、共用ＤＲＡＭデータバスの方向に基づく要求スケジューリングである。典型的に、ＤＲＡＭデータバスの方向を読み取りから書き込みへそしてその逆に切り換えることに関連したコストがある。従って、各要求間で切り換えるのではなく、同じデータバス方向を必要とする要求を一緒に集めるのが効果的である。どれほど多くの要求を一緒に集めるかは、予想される要求入力パターン、及び効率と待ち時間との間の妥協に依存し、その一例が図４に示されている。ＤＲＡＭスケジューリングアルゴリズムが方向を頻繁に切り換えるようにセットされた場合には、多数の切り換えが多くのデータバスサイクルを浪費させるので、予想される効率は低い。一方、要求が到着するや否やサービス状態となるので、要求の平均待機時間（待ち時間）は低い。
【００１９】
ＤＲＡＭスケジューリングアルゴリズムが、頻繁に切り換わらない（即ち各方向の要求をより多く集める）ようにセットされた場合には、全ＤＲＡＭ効率は高くなるが、要求の平均待ち時間も長くなる。全システム性能の最良のポイントは容易に決定されず、これは、要求パターン、待ち時間と効率との間の妥協、及び切り換えのコストに依存する。
【００２０】
以下の例は、バス方向をコスト関数スケジューリングの基礎として使用する。しかしながら、種々の他の基準を使用して、コスト関数スケジューリングを実施することも意図される。コスト関数スケジューリングの他の例は、１つのＤＲＡＭページをいつ閉じそして別のページをいつ開くか判断し、そしてＤＲＡＭ要求をいつ切り換えて異なる物理的バンクを使用するか判断することを含む。
【００２１】
図５は、最適なパーフォーマンスに対してスイッチ点の動的な調整ができるようにプログラム可能なＤＲＡＭバススケジューラの１実施例を示している。１つの実施例において、スケジューラ５０５は、データバスの最後の方向（読み出し又は書き込み）５１０のトラック及びその方向を持ったリクエストの数のカウント５１５を維持する。スイッチ点情報を保持するためにレジスタ５２０が加えられる。１つの実施例では、このレジスタ５２０に、最適なパーフォーマンスに対してＤＲＡＭスケジューラを動的に構成するためにシステムの動作中にソフトウェア５２５により書き込むことができる。たとえば、アプリケーションに従って及び／又はアプリケーションによりスイッチ点を動的に更新することが望ましい。１つの実施例では、スイッチ点は、過去又は現在のパーフォーマンスに基づいて経験的に決定される。
【００２２】
リクエストは異なるスレッド上で提供されるので、スケジューラ５０５が、ＤＲＡＭデータバスの現在の方向、既に送られたリクエストのカウント、構成可能なスイッチ点、及び入来する新しいリクエストの方向を見る。カウントがスイッチ点に到達する前では、現在のＤＲＡＭデータバスと同じ方向を持つリクエストの方がそれらが逆方向へ進むものよりも選択される。スイッチ点に到達すると、逆方向へのリクエストが選択される。１つの方向からのリクエストだけが提供される場合には、次のリクエストがどちらの方向へ進むかは全く選択されない。本実施例では、スイッチ点を決定するためにカウント及び比較ファンクションが使用される。しかしながら、他のファンクションを使用することも考慮される。さらに、この例では、カウント及び他のファンクションをバス方向に適用したが、カウントに対してあらゆるタイプの手段が使用できる。
【００２３】
プロセスの１つの実施例が図６により示されている。ステップ６０５において、少なくとも１つのリクエストが利用可能であると考えると、バスの現在の方向についてリクエストがあるかどうかが決定される。リクエストがなければ、バスの方向が変更され（ステップ６１０）カウントリセット（ステップ６１５）し、バスの新しい方向を使用してリクエストが処理される（６２０）。現在のバスの方向で実行されたリクエストの数のトラックを維持するカウントがインクリメントされる（ステップ６２５）。バスのカウント方向についてリクエストがある場合には、その後、カウントがスイッチ点に到達したかどうかがチェックされる。その後スイッチ点に到達した場合には、バスの逆方向についてリクエストがあるかどうかが決定される（ステップ６３５）。スイッチ点に到達していない場合には、現在の方向についてリクエストが処理される（ステップ６２０）。加えて、カウントがスイッチ点に到達していない場合には、処理されている現在の方向についてリクエストの処理を続行し、カウントがインクリメントされる（ステップ６２０及び６２５）。
【００２４】
１つ実施例では、サービススケジューリングとＤＲＡＭスケジューリングのスレッド品質を結合してＤＲＡＭ効率を最大にしながら各スレッドについて所望のサービスの品質を残すスケージュリング結果を達成するのが望ましい。異なるスケジューリングコンポーネントを結合する１つの方法は、それらを１つ以上のリクエストフィルタ（その１つが図７に示されている）として表すことである。パースレッドリクエスト７０５が入力され、そして選択的にフィルタされ、それにより、リクエストの一部のセットのみが、フィルタ７１０を介してフィルタリングされ、すなわちフィルタ７１０から出力される。どのリクエストがフィルタ出力されるべきかの決定は、フィルタに取り付けられた制御ユニット７１５により行われる。このユニット７１５は、この決定を入来するリクエスト及び可能ならばユニット７１５のある状態に基づいて行う。たとえば、ＤＲＡＭの方向を切り換えることを決定するコストファンクションフィルタについては、その決定は、バスの現在の方向、最後の切り換え以降に既にその方向に通過したリクエストの数及び異なるスレッドから提供されるリクエストのタイプに基づいて実行される。この決定は、ＤＲＡＭデータバスと同じ方向について続行されるかもしれないし、したがって、逆方向のリクエストがあればフィルタ出力される。
【００２５】
異なるスケジューリングコンポーネントがフィルタとして表されると、各種フィルタをスタックしてスケジュールコンポーネントを結合することができる。フィルタをスタックする順序は、異なるスケジューリングコンポーネントに与えられる優先順位を決定する。
【００２６】
図８は、所望の結果を達成するための、２つのスケジューリングアルゴリズムの異なる部分の順序付けを示す１つの実施例のブロック図である。図８に示されたブロック８１０、８２０、８３０、８４０の各々は、リクエストが入力されて（８０５）出力される（８６０）のに対して１つのフィルタのように作用する。各フィルタに対して、たとえば、各フィルタ８１０、８２０、８３０について、そのスケージュリングのステージの基準を満たすリクエストのみが通過を許される。たとえば、ＤＲＡＭバンクスケジューリング８１０は、利用可能なバンクに対するリクエストだけ通過を許し、基準を満たさないリクエストをフィルタ出力する。サービススケジューリング８２０のスレッド品質が、所望の優先順位グループにあるスレッドだけの通過を許す。データバススケジューリング、コストファンクションスケジューリングの１つの例８３０は、データバスのターンアラウンドを避けるために選択的に書き込み又は読み出しのみを通過させる。
【００２７】
詳細には、１つの実施例において、異なるスレッドからのＤＲＡＭリクエスト８０５が入力され絶対ＤＲＡＭスケジューリングコンポーネント８１０が実行され、それにより、ＤＲＡＭに送ることができないリクエストがフィルタ出力され、送ることができるリクエストだけがスレッドスケジューラ８２０へ送り続けられる。スレッドスケジューラ８２０は、各スレッドについてサービス品質条件を使用してリクエストをスケジュールする。スケジューラ８２０は、この時点でサービスを受けるべきでないスレッドからのリクエストをフィルタ出力する。残りのリクエストはコストファンクションＤＲＡＭスケジューラ８３０へ続けて送られる。ここで、リクエストはコストファンクションスケジューリングに従って除去される。ＤＲＡＭスケジューリングに対して１つ以上のコストファンクションコンポーネントがある場合には、異なるコンポーネントが最大のスイッチコストから最小のコストへ順序付けられる。たとえば、データバスターンアラウンドに３サイクルのコストがかかり、１つの物理ＤＲＡＭバンクから別の物理ＤＲＡＭバンクへの切り換えに１サイクルのコストがかかる場合には、物理ＤＲＡＭバンクの代用としてＤＲＡＭデータバススケジューリングが使用される。１つ以上のリクエストがコストファンクションＤＲＡＭスケジューラの最下部から出力される場合には、それらは、到着時間の優先順位で順序付けられる。この最後のフィルタ８４０はリクエストがそれらのスレッド優先順位グループ内で衰弱するのを防止する。
【００２８】
上述した説明は、正にＤＲＡＭスケジューリングシステムの１つの実施例に過ぎない事は容易に明らかであろう。異なるスレッシュホールドを有する異なるタイプのフィルタ及びフィルタのスイッチ点及び／又は異なる順序付けが所望の結果を達成するために実施されてもよい事は容易に認識されるであろう。さらに、図面では別のフィルタエレメントとして示されているが、そのフィルタを、単一の論理プロセッサ又はプロセスにより実施して、上述したフィルタファンクションを表すプロセスのステージを実行してもよい。以上、本発明を１つの実施例について説明したが、多数の代替物、修正、変更及び使用が当業者にとって明らかであろう。
【図面の簡単な説明】
【図１】
本発明のシステムの一実施形態を示す図である。
【図２】
スレッドのスケジューリングとデバイスのスケジューリングを合成する一実施形態を示す簡単なフローチャートである。
【図３】
ＤＲＡＭ及びスレッドスケジューラーの一実施形態を示す図である。
【図４】
コスト関数スケジューリングの妥協を示す簡単な例である。
【図５】
コスト関数ＤＲＡＭバススケジューラーの一実施形態を示す図である。
【図６】
コスト関数ＤＲＡＭバススケジューリングプロセスの一実施形態を示すフローチャートである。
【図７】
要求フィルタとしてのスケジューリングコンポーネントの一実施形態を示す図である。
【図８】
所望の結果を得るようにスレッドスケジューリング及びデバイススケジューリングを順序付けする一実施形態を示す図である。

Claims (14)

1. リクエストスレッドを処理するためのサービスの品質（ＱＯＳ）スケジューリングを、各スレッドについてのＱＯＳを実質的に維持するように組合せることと、リソースの効率を実質的に最大にするリソーススケジューリングとを包含する、リソースへのアクセスをスケジュールする方法。
2. 請求項１に記載の方法において、前記組合せることが、決定されたステージ（各ステージがＱＯＳの１つを反映している）でのリクエストをフィルタリングすることと、前記ステージを、決定されて組合されたＱＯＳ及びリクエストのプライオリティのリソーススケジュールを達成するように、順序付けすることとを包含することを特徴とする方法。
3. 請求項２に記載の方法において、前記ステージは、ＱＯＳ保証に合わせるためリクエストの順序を決定するように且つリソース効率のリクエストの順序を決定するように順序付けされ、リソース効率がＱＯＳ保証を満足する場合にはリクエストが第１のリソース効率順序に従ってスケジュールされ、それ以外の場合にはリクエストが第２のリソース効率順序に従ってスケジュールされる、ことを特徴とする方法。
4. 請求項２に記載の方法において、前記リソースが、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）であり、前記ステージが、ＱＯＳ保証に合わせるためリクエストの順序を決定するように且つＤＲＡＭ効率のリクエストの順序を決定するように順序付けされ、前記ＤＲＡＭ効率がＱＯＳ保証を満足する場合にはリクエストが第１のＤＲＡＭ効率順序に従ってスケジュールされ、それ以外の場合にはリクエストが第２のＤＲＡＭ効率順序に従ってスケジュールされる、ことを特徴とする方法。
5. 請求項２に記載の方法において、前記フィルタリングすることが、
   前記リソースのアベイラビリティによって送られ得るリクエストを通してフィルタリングすること、
   ＱＯＳ保証に合わせるリクエストを通してフィルタリングすること、
   前記リソースのコストファンクションスケジューリングによるリクエストを通してフィルタリングすること、及び
   前記リソースによって処理するための前記フィルタリングされたリクエストを提供すること
   を包含することを特徴とする方法。
6. 請求項５に記載の方法において、前記リソースのコストファンクションスケジューリングによるリクエストを通してフィルタリングすることが、最高のスイッチコストから最低のものへ順序付けされたものをフィルタリングすることを包含することを特徴とする方法。
7. 請求項５に記載の方法において、前記提供することにおいて複数のリクエストが含まれる場合、更に、前記スケジューリングリクエストを、到着時間に従ってプライオリティの順序付けを行うことを包含することを特徴とする方法。
8. 請求項５に記載の方法において、前記リソースは、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）であることを特徴とする方法。
9. デバイスへのアクセスをスケジューリングするスケジューリング装置であって、
   リクエストスレッドを処理するための、組合せたサービス品質（ＱＯＳ）のスケジューラを包含し、各スレッドについてのＱＯＳが実質的に維持されており、更に、リソース効率が実質的に最大にされるリソーススケジューラを包含する、ことを特徴とするスケジューリング装置。
10. 請求項９に記載の装置において、前記組合せたＱＯＳスケジュールが、複数のリクエストフィルタを包含し、各フィルタは、ＱＯＳの１つとリソーススケジューリング基準を反映し、前記フィルタが、決定されて組合されたＱＯＳ及びリクエストのプライオリティのリソーススケジュールを達成するように順序付けられる、ことを特徴とする装置。
11. 請求項１０に記載の装置において、前記複数のフィルタの第１のフィルタは、前記リソースの非アベイラビリティによっては送られ得ないリクエストをフィルタ出力しており、前記第１フィルタは、ＱＯＳ保証に従うリクエストをフィルタ出力するように第２のフィルタに第１フィルタ出力リクエストを提供し、前記第２フィルタは、前記リソースのコストファンクションスケジューリングに従うリクエストをフィルタ出力するように第３のフィルタに第２フィルタ出力リクエストを提供し、該第３フィルタが前記リソースによって処理するための第３フィルタ出力を提供する、ことを特徴とする装置。
12. 請求項１１に記載の装置において、前記リソースが、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）である、ことを特徴とする装置。
13. 請求項１１に記載の装置において、前記第３フィルタが、最高のスイッチコストから最低のものへ順序付けされた複数のサブフィルタを包含することを特徴とする装置。
14. 請求項１１に記載の装置において、前記第３フィルタが複数のリクエストを提供する場合、該リクエストは、スケジューリングの到着時間に従ってプライオリティが順序付けされることを特徴とする装置。

Images