JP5348315B2 - マルチコアプロセッサシステム、制御プログラム、および制御方法 - Google Patents
マルチコアプロセッサシステム、制御プログラム、および制御方法 Download PDFInfo
- Publication number
- JP5348315B2 JP5348315B2 JP2012505430A JP2012505430A JP5348315B2 JP 5348315 B2 JP5348315 B2 JP 5348315B2 JP 2012505430 A JP2012505430 A JP 2012505430A JP 2012505430 A JP2012505430 A JP 2012505430A JP 5348315 B2 JP5348315 B2 JP 5348315B2
- Authority
- JP
- Japan
- Prior art keywords
- application
- access
- priority
- highest
- remaining
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
- G06F9/526—Mutual exclusion algorithms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/16—Handling requests for interconnection or transfer for access to memory bus
- G06F13/1605—Handling requests for interconnection or transfer for access to memory bus based on arbitration
- G06F13/1652—Handling requests for interconnection or transfer for access to memory bus based on arbitration in a multiprocessor architecture
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Multi Processors (AREA)
Description
本発明は、マルチコアプロセッサが共有する共有資源へのアクセスを調停する調停回路を制御するマルチコアプロセッサシステム、制御プログラム、および制御方法に関する。
従来、物理的なメモリが1つであり、全CPUがバスなどを介して当該メモリ(以下、「共有メモリ」と称する。)に接続される共有メモリ型のマルチコアプロセッサ(以下、マルチコアプロセッサシステムと称する。)が知られている。マルチコアプロセッサシステムにおいて、メインOSがスケジューラにより各CPUに割り当てるアプリケーションソフトウェア(以下、「アプリケーション」と称する。)を決定していた(たとえば、下記特許文献1〜4参照。)。
共有メモリ型のマルチコアプロセッサシステムでは、各CPUが共有メモリに対してアクセスするためにアクセスの競合が発生してしまう。そこで、マルチコアプロセッサシステムには、アクセスの競合を防止するために各CPUからのアクセスを調停する調停回路が備えられている。
アクセスの調停方式は、ラウンドロビン方式と重み付けラウンドロビン方式と優先度制御方式との3つの方式が知られている。調停回路はアクセス要求が登録されているリクエストバッファから順にアクセス要求を取り出し、該アクセス要求を許可する。調停回路は、該3つの方式から任意の方式によってアクセス比率が定められ、アクセス比率に応じてリクエストバッファへの登録順を制御することでアクセス要求を調停していた。アクセス比率とは、各コアに与えるアクセス時間の比率である。ここでは、理解の容易化のために、各アクセス要求の必要アクセス時間をすべて同一の時間として説明する。
ここでは、一のCPUに割り当てられたアプリA(アプリケーションA)のアクセス要求と一のCPUと異なる他のCPUに割り当てられたアプリB(アプリケーションB)のアクセス要求とが調停回路へ通知される場合を例に挙げて3つの方式を詳細に説明する。
まず、ラウンドロビン方式では、各プロセッサコアのアクセス時間であるタイムスライスが設定されており、各プロセッサコアに均等に共有資源へのアクセス権を与える方式である。たとえば、アプリAとアプリBのアクセス比率を1対1とし、タイムスライスが各アクセス要求の必要アクセス時間であるとすると、アプリAのアクセス要求とアプリBのアクセス要求がリクエストバッファへ交互に登録される。また、アプリAとアプリBのアクセス比率とは、アプリAが割り当てられているCPUに与えるアクセス権のアクセス時間とアプリBが割り当てられているCPUに与えるアクセス権のアクセス時間との比率である。
つぎに、重み付けラウンドロビン方式では、アプリAとアプリBのアクセス比率をアプリAの優先度対アプリBの優先度とする。たとえば、アプリAの優先度が90であり、アプリBの優先度が80である場合、アプリAとアプリBのアクセス比率は9対8である。タイムスライスが各アクセス要求の必要アクセス時間であるとすると、アプリAのアクセス要求が9つ登録される都度、アプリBのアクセス要求が8つ登録される。
最後に、優先度制御方法では、アプリAの優先度がアプリBの優先度以上の場合、アプリAとアプリBのアクセス比率をリクエストバッファがアクセス要求を登録可能な最大登録数対1とする。ここでは、最大登録数を9とする。ここでは、上述のようにリクエストバッファが9つのアクセス要求が登録可能であり、タイムスライスが各アクセス要求の必要アクセス時間であるとすると、アプリAのアクセス要求が9つ登録される都度、アプリBのアクセス要求が1つ登録される。
しかしながら、どのアプリケーションが割り当てられているかの組み合わせによって3つの調停方式のどの調停方式が最適であるかが変化するが、調停回路では調停方式は上述の3つの方式のうちいずれか一つの方式に固定されている。ラウンドロビン方式であれば、もし優先度が高いアプリケーションと優先度が低いアプリケーションとがCPUに割り当てられていた場合、アクセス比率が1対1で固定であるため、優先度が高いアプリケーションのアクセスを優先させることができないという問題点があった。
また、優先度制御方式であれば、優先度が高いアプリケーションのアクセスを早期に終了させることができるが、優先度が低いアプリケーションはアクセス要求が許可されるまで待機しなければならなかった。すなわち、優先度が低いアプリケーションの共有資源へのアクセス回数が多いとアクセス待ちの時間が増加し、優先度が低いアプリケーションの処理が遅くなる問題点があった。
また、重み付けラウンドロビン方式であれば、優先度が同一の2つのアプリケーションであっても、一方のアプリケーションはアクセス回数が多く、他方のアプリケーションはアクセス回数が少ないと、一方のアプリケーションが待機する時間が増加し、一方のアプリケーションの処理が遅くなる問題点があった。
すなわち、調停回路ではアクセス比率が固定されているため、各CPUに割り当てられたアプリケーションの組み合わせによって、該アクセス比率に応じた問題点が生じていた。
本発明は、上述した従来技術による問題点を解消するため、最適なアクセス比率によりマルチコアプロセッサから共有資源へのアクセスを調停回路に調停させることができるマルチコアプロセッサシステム、制御プログラム、および制御方法を提供することを目的とする。
本実施形態の一態様として、マルチコアプロセッサと、前記マルチコアプロセッサが共有する共有資源と、前記マルチコアプロセッサから前記共有資源へのアクセスをアクセス比率に応じて調停する調停回路と、を備えるマルチコアプロセッサシステムであって、前記マルチコアプロセッサにおいてアプリケーションの切り替え処理または割り当て処理を検出し、前記切り替え処理または前記割り当て処理が検出された場合、前記マルチコアプロセッサの各コアに割り当てられたアプリケーションの実行に関する優先度および前記共有資源へのアクセス回数を取得し、前記割り当てられたアプリケーションのうち、取得された優先度が最も高いアプリケーションを除く残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較することにより、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を決定し、決定されたアクセス比率を前記調停回路へ通知するマルチコアプロセッサシステムを提供する。
開示のマルチコアプロセッサシステム、制御プログラム、および制御方法によれば、最適なアクセス比率によりマルチコアプロセッサから共有資源へのアクセスを調停回路に調停させることができるという効果を奏する。
以下に添付図面を参照して、本発明によるマルチコアプロセッサシステム、制御プログラム、および制御方法の好適な実施の形態を詳細に説明する。
(マルチコアプロセッサシステムのハードウェア構成)
図1は、実施の形態にかかるマルチコアプロセッサシステムのハードウェア構成を示すブロック図である。図1において、マルチコアプロセッサシステム100は、CPU#0〜CPU#2と調停回路102と共有メモリ103とを備えている。また、CPU#0〜CPU#2と調停回路102は、バス101によってそれぞれ接続され、共有メモリ103は調停回路102を介してCPU#0〜CPU#2とそれぞれ接続されている。
図1は、実施の形態にかかるマルチコアプロセッサシステムのハードウェア構成を示すブロック図である。図1において、マルチコアプロセッサシステム100は、CPU#0〜CPU#2と調停回路102と共有メモリ103とを備えている。また、CPU#0〜CPU#2と調停回路102は、バス101によってそれぞれ接続され、共有メモリ103は調停回路102を介してCPU#0〜CPU#2とそれぞれ接続されている。
ここで、マルチコアプロセッサとは、コアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。
CPU#0〜CPU#2は、それぞれレジスタやキャッシュを備えている。CPU#0は、OS111を実行し、マルチコアプロセッサシステム100の全体の制御を司る。CPU#1〜CPU#2は、それぞれOS112とOS113を実行し、OS111に割り当てられたアプリケーション(またはプロセス)を実行する。OS111は、マスタOSであり、アプリケーションの割り当てを制御するスケジューラ114と調停回路102を制御する制御プログラムを備えている。OS112とOS113はスレーブOSである。
調停回路102は、CPU#0〜CPU#2から共有メモリ103へのアクセスを調停する回路である。具体的には、調停回路102は、CPU#0〜CPU#2のそれぞれに割り当てられているアプリケーションからのアクセス要求をリクエストバッファへ登録し、リクエストバッファに登録されている順にアクセス要求を取り出し、取り出したアクセス要求を許可する。
そして、共有メモリ103は、マルチコアプロセッサに共有されるメモリであり、アプリ情報群121やプロセステーブル122やOS111〜OS113などのプログラムを記憶している。共有メモリ103は、具体的には、ROM(Read Only Memory)と、RAM(Random Access Memory)と、フラッシュROMなどを備えている。
たとえば、ROMが、該プログラムなどを記憶し、RAMは、CPU#0〜CPU#2のワークエリアとして使用される。共有メモリ103に記憶されているプログラムは、各CPUにロードされることで、コーディングされている処理をCPUに実行させることとなる。本実施の形態では、調停回路102を制御する制御プログラムがOS111に備えられており、CPU#0がOS111をロードしてコーディングされている処理を実行するため、該制御プログラムにコーディングされている処理はCPU#0が実行することとなる。また、本実施の形態ではOS111が該制御プログラムを備えているが、これに限らず、OS112またはOS113が備えていてもよい。
プロセステーブル122は、起動しているアプリケーション(またはプロセス)がどのCPUに割り当てられているか、割り当てられているCPUが該アプリケーションに関する処理を実行中であるか否かを示す情報である。各CPUは、プロセステーブル122を読み出して各CPUのキャッシュに記憶しておく。CPU#0はスケジューラ114によりアプリケーションを割り当てるとプロセステーブル122に登録する。各CPUはタスクスイッチが発生するとプロセステーブル122にどのアプリケーションが実行状態になったかを登録する。そして、各CPUは、プロセステーブル122を書き換えると、スヌープ処理を実行することで、全CPUのキャッシュに記憶されているプロセステーブル122を更新する。
CPU#0は、プロセステーブル122に変更があるか否かによってタスクディスパッチやタスクスイッチが発生したことを検出することができる。
アプリ情報群121は、アプリケーション群と各アプリケーションの実行に関する優先度と共有メモリ103へのアクセス回数とを示すタグ情報が付されている情報である。アプリ情報群121の詳細については後述する。
また、図示していないが、マルチコアプロセッサシステム100では、I/F(InterFace)やディスプレイやキーボードなどを備えている。I/Fは、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークに接続され、当該ネットワークを介して他の装置に接続される。そして、I/Fは、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/Fには、たとえばモデムやLANアダプタなどを採用することができる。
ディスプレイは、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。ディスプレイは、たとえば、CRT、TFT液晶ディスプレイ、プラズマディスプレイなどを採用することができる。キーボードは、文字、数字、各種指示などの入力のためのキーを備え、データの入力を行う。また、タッチパネル式の入力パッドやテンキーなどであってもよい。
(アプリ情報群121)
図2は、アプリ情報群121の一例を示す説明図である。アプリ情報群121では、アプリA〜アプリG(アプリケーションG)までのアプリケーションにタグ情報が付されている。タグ情報には実行に関する優先度と共有メモリ103へのアクセス回数が含まれている。
図2は、アプリ情報群121の一例を示す説明図である。アプリ情報群121では、アプリA〜アプリG(アプリケーションG)までのアプリケーションにタグ情報が付されている。タグ情報には実行に関する優先度と共有メモリ103へのアクセス回数が含まれている。
なお、共有資源へのアクセス回数は、アプリケーションの開発時にESL(Electronic System Level)でシミュレーションを実施することにより得られる情報である。優先度は利用者が定める情報である。たとえば、通話やメールに関するアプリケーションは他のアプリケーションと比較して優先度が高い。
アプリAのタグ情報201は優先度が90であり、アクセス回数が90である。アプリBのタグ情報202では優先度が80であり、アクセス回数が20である。アプリC(アプリケーションC)のタグ情報203では優先度が40であり、アクセス回数が80である。アプリD(アプリケーションD)のタグ情報204では優先度が30であり、アクセス回数が90である。アプリE(アプリケーションE)のタグ情報205では優先度が20であり、アクセス回数が10である。アプリF(アプリケーションF)のタグ情報206では優先度が30であり、アクセス回数が30である。アプリGのタグ情報207では優先度が30であり、アクセス回数が90である。
(マルチコアプロセッサシステム100の機能的構成)
図3は、本実施の形態にかかるマルチコアプロセッサシステム100の機能的構成を示すブロック図である。マルチコアプロセッサシステム100は、検出部301と、取得部302と、特定部303と、比較部304と、決定部305と、通知部306と、を含む構成である。各機能(検出部301〜通知部306)は、具体的には、たとえば、図1に示した共有メモリ103に記憶された制御プログラムをCPU♯0に実行させることによりその機能を実現する。
図3は、本実施の形態にかかるマルチコアプロセッサシステム100の機能的構成を示すブロック図である。マルチコアプロセッサシステム100は、検出部301と、取得部302と、特定部303と、比較部304と、決定部305と、通知部306と、を含む構成である。各機能(検出部301〜通知部306)は、具体的には、たとえば、図1に示した共有メモリ103に記憶された制御プログラムをCPU♯0に実行させることによりその機能を実現する。
検出部301は、マルチコアプロセッサにおいてアプリケーションのタスクスイッチまたはタスクディスパッチを検出する。タスクスイッチとは、周知のように各CPUが実行するアプリケーションを切り替える切り替え処理である。タスクディスパッチは、周知のようにスケジューラ114がアプリケーションをマルチコアプロセッサの各CPUに割り当てる割り当て処理である。
取得部302は、検出部301によりタスクスイッチまたはタスクディスパッチが検出された場合、マルチコアプロセッサのコアごとに割り当てられたアプリケーションの実行に関する優先度および共有メモリ103へのアクセス回数を取得する。
特定部303は、取得部302により優先度およびアクセス回数が取得されると、割り当てられたアプリケーションのうち取得部302により取得された優先度が最も高いアプリケーションを特定する。
比較部304は、割り当てられたアプリケーションのうち特定部303により特定された優先度が最も高いアプリケーションを除く残余のアプリケーションごとに取得部302により取得されたアクセス回数と特定されたアプリケーションのアクセス回数とを比較する。
決定部305は、残余のアプリケーションごとに残余のアプリケーションと最も高いアプリケーションとのアクセス比率を比較部304により比較された比較結果に基づいて決定する。
通知部306は、決定部305により決定されたアクセス比率を調停回路102へ通知する。
また、比較部304は、特定されたアプリケーションの優先度と残余のアプリケーションの優先度が等しいか否かを判断する。
決定部305は、比較部304により特定されたアプリケーションの優先度と残余のアプリケーションの優先度が等しいと判断され、かつ特定されたアプリケーションのアクセス回数と残余のアプリケーションのアクセス回数が等しいと判断された場合において、特定されたアプリケーションと残余のアプリケーションとのアクセス比率を1対1に決定する。そして、通知部306は、決定部305により決定されたアクセス比率を調停回路102へ通知する。
決定部305は、比較部304により特定されたアプリケーションの優先度と残余のアプリケーションの優先度が等しいと判断され、かつ特定されたアプリケーションのアクセス回数と残余のアプリケーションのアクセス回数が等しくないと判断された場合、特定されたアプリケーションと残余のアプリケーションとのアクセス比率を特定されたアプリケーションのアクセス回数対残余のアプリケーションのアクセス回数に決定する。そして、通知部306は、決定部305により決定されたアクセス比率を調停回路102へ通知する。
決定部305は、比較部304により特定されたアプリケーションの優先度と残余のアプリケーションの優先度が等しいと判断され、かつ特定されたアプリケーションのアクセス回数と残余のアプリケーションのアクセス回数が等しくないと判断された場合、特定されたアプリケーションと残余のアプリケーションとのアクセス比率を特定されたアプリケーションのアクセス回数対残余のアプリケーションのアクセス回数に決定する。そして、通知部306は、決定部305により決定されたアクセス比率を調停回路102へ通知する。
決定部305は、比較部304により特定されたアプリケーションの優先度と残余のアプリケーションの優先度が等しくないと判断され、かつ残余のアプリケーションのアクセス回数が特定されたアプリケーションのアクセス回数未満であると判断された場合、特定されたアプリケーションと残余のアプリケーションとのアクセス比率を所定数対1に決定する。ここで、所定数は、リクエストバッファがアクセス要求を登録可能な最大登録数である。そして、通知部306は、決定部305により決定されたアクセス比率を調停回路102へ通知する。
以上を踏まえて、本実施の形態にかかるマルチコアプロセッサでの制御処理について図を用いて実施例を説明する。まず、マルチコアプロセッサシステム100の各CPUがOSを起動し、OSの各処理の実行を開始すると、CPU#0が共有メモリ103にアクセスしてアプリ情報群121から各アプリケーションのタグ情報を取得し、取得したタグ情報をキャッシュに記憶する。
図4は、CPU#0にアプリAがディスパッチされた例を示す説明図である。図4では、アプリAがCPU#0に割り当てられているが、他のCPUには何も割り当てられていないため、CPU#0が、アプリAのアクセス比率を1に決定し、決定したアクセス比率を調停回路102へ通知する。よって、アプリAが調停回路102へアクセス要求を通知すると、調停回路102は受け付けたアクセス要求をリクエストバッファへ登録する。本実施の形態では、リクエストバッファのバッファ数は9とする。
図5は、CPU#1にアプリBがディスパッチされた例を示す説明図である。アプリBがCPU#1にディスパッチされると、CPU#0は、該ディスパッチを検出し、マルチコアプロセッサの各CPUに割り当てられているアプリケーションを特定して実行アプリ群とする。ここでは、実行アプリ群が下記である。
・実行アプリ群:アプリA、アプリB
つぎに、CPU#0が、実行アプリ群内の各アプリケーションのタグ情報をキャッシュから取得し、優先度が高い順にソートして未決定キューに入れる。アプリAの優先度が90であり、アプリBの優先度が80である。未決定キューはアクセス比率が未決定なアプリケーションが登録されているキューであり、決定済アプリ群はアクセス比率が未決定なアプリケーションが登録されているバッファである。
・未決定キュー:アプリA→アプリB
・決定済アプリ群:φ
・決定済アプリ群:φ
そして、CPU#0が、未決定キューから最も優先度が高いアプリケーションを取り出し、取り出したアプリケーションを未決定キューから削除し、取り出したアプリケーションを決定済アプリ群に登録する。ここでは、未決定キューからアプリAが取り出され、決定済アプリ群に入れられる。
・未決定キュー:アプリB
・決定済アプリ群:アプリA
・決定済アプリ群:アプリA
つぎに、CPU#0が未決定キューからアプリBを取り出す。そして、CPU#0が、取り出したアプリBの優先度と決定済アプリ群の最も優先度が高いアプリであるアプリAの優先度とを比較して同一であるか否かを判断する。
アプリBの優先度はアプリAの優先度と同一でないと判断される。そして、CPU#0が、アプリBのアクセス回数はアプリAのアクセス回数以上であるか否かを判断する。アプリBのアクセス回数が20であり、アプリAのアクセス回数が90であるため、CPU#0が、アプリBのアクセス回数はアプリAのアクセス回数未満であると判断する。
そして、アプリBのアクセス回数がアプリAのアクセス回数未満であると判断されると、CPU#0が、アプリAとアプリBとのアクセス比率をリクエストバッファのバッファサイズ対1とする。リクエストバッファのバッファサイズが9であるため、CPU#0が、アプリAが9に対してアプリBが1に決定し、調停回路102へ決定したアクセス比率を通知する。すなわち、アプリAとアプリBとが優先度制御方式を用いて調停される。
図6は、アクセス比率に応じてマルチコアプロセッサから共有メモリ103へのアクセスを調停する例を示す説明図(その1)である。本実施の形態では、理解の容易化のために、各アクセス要求の必要アクセス時間がすべて同一時間であると仮定し、タイムスライスを該必要アクセス時間として説明する。調停回路102はアクセス比率の通知を受け付けると、リクエストバッファ600にアプリAのアクセス要求を9つ登録する。つぎに、アプリAのアクセス要求が1つ終了すると、アプリBのアクセス要求を1つ登録する。さらに、アプリAのアクセス要求が1つ終了すると、アプリAのアクセス要求を1つ登録する。したがって、アプリAとアプリBのアクセス比率が9対1であるとは、調停回路102がアプリAのアクセス要求を9つ登録する都度、アプリBのアクセス要求を1つ登録することである。
図7は、CPU#2にアプリCがディスパッチされた例を示す説明図である。図11では、アプリCがCPU#2にディスパッチされると、CPU#0は、該ディスパッチを検出し、マルチコアプロセッサの各CPUに割り当てられているアプリケーションを特定して実行アプリ群とする。ここでは、実行アプリ群が下記である。
・実行アプリ群:アプリA、アプリB、アプリC
つぎに、CPU#0が、実行アプリ群の各アプリケーションの優先度とアクセス回数を取得し、優先度が高い順にソートして未決定キューに入れる。すなわち、未決定キューの先頭に入っているアプリケーションが、優先度が最も高いアプリケーションである。
・未決定キュー:アプリA→アプリB→アプリC
・決定済アプリ群:φ
・決定済アプリ群:φ
そして、CPU#0が、未決定キューから最も優先度が高いアプリケーションを取り出し、取り出したアプリケーションを未決定キューから削除する。ここでは、未決定キューからアプリAが取り出され、決定済アプリ群に入れられる。
・未決定キュー:アプリB→アプリC
・決定済アプリ群:アプリA
・決定済アプリ群:アプリA
つぎに、CPU#0が、未決定キューからアプリBを取り出し、取り出したアプリBを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリケーションを取り出す。アプリAとアプリBのアクセス比率は上述と同一で9対1であり、CPU#0が、調停回路102へアプリAとアプリBとのアクセス比率を通知する。
・未決定キュー:アプリC
・決定済アプリ群:アプリA、アプリB
・決定済アプリ群:アプリA、アプリB
つぎに、未決定キューからアプリCが取り出され、アプリCの優先度が決定済アプリ群のアプリAの優先度と同一であるか否かが判断される。ここでは、アプリCの優先度とアプリAの優先度が同一でないと判断される。
そして、CPU#0が、アプリAのアクセス回数とアプリCのアクセス回数を比較して、アプリCのアクセス回数がアプリAのアクセス回数以上であるか否かを判断する。アプリCのアクセス回数がアプリAのアクセス回数未満であるため、アプリAとアプリCのアクセス比率は9対1に決定される。CPU#0が、調停回路102へアプリAとアプリCとのアクセス比率を通知し、決定済アプリ群にアプリCを入れる。
・未決定キュー:φ
・決定済アプリ群:アプリA、アプリB、アプリC
・決定済アプリ群:アプリA、アプリB、アプリC
未決定キューがφ(空)であるため、CPU#0は、各CPUに割り当てられたすべてのアプリのアクセス比率を決定したと判断する。
図8は、アクセス比率に応じてマルチコアプロセッサから共有メモリ103へのアクセスを調停する例を示す説明図(その2)である。調停回路102はアクセス比率の通知を受け付けると、リクエストバッファ600にアプリAのアクセス要求を9つ登録する。つぎに、アプリAのアクセス要求が1つ終了すると、アプリBのアクセス要求を1つ登録する。さらに、アプリAのアクセス要求が1つ終了すると、アプリCのアクセス要求を1つ登録する。
すなわち、アプリAとアプリBのアクセス比率が9対1であるため、リクエストバッファ600へアプリAのアクセス要求が9つ登録される都度、アプリBのアクセス要求が1つ登録される。また、アプリAとアプリCのアクセス比率が9対1であるため、リクエストバッファ600へアプリAのアクセス要求が9つ登録される都度、アプリCのアクセス要求を1つ登録される。
図9は、CPU#1でアプリBからアプリDにタスクスイッチが発生した例を示す説明図である。CPU#1にアプリBが割り当てられていたが、タスクスイッチによりCPU#1にアプリDが割り当てられている。CPU#0が、該タスクスイッチを検出し、マルチコアプロセッサの各CPUに割り当てられているアプリケーションを特定して実行アプリ群とする。ここでは、実行アプリ群が下記である。
・実行アプリ群:アプリA、アプリD、アプリC
つぎに、CPU#0が、実行アプリ群の各アプリケーションの優先度とアクセス回数を取得し、優先度が高い順にソートして未決定キューに入れる。すなわち、未決定キューの先頭に入っているアプリが各CPUに割り当てられたアプリケーションの中で優先度が最も高いアプリケーションである。未決定キューは下記の様になる。
・未決定キュー:アプリA→アプリC→アプリD
・決定済アプリ群:φ
・決定済アプリ群:φ
そして、CPU#0が、未決定キューの先頭からアプリを取り出し、取り出したアプリを未決定キューから削除する。ここでは、未決定キューからアプリAが取り出され、決定済アプリ群に入れられる。
・未決定キュー:アプリC→アプリD
・決定済アプリ群:アプリA
・決定済アプリ群:アプリA
つぎに、CPU#0が、未決定キューからアプリCを取り出し、取り出したアプリを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリを取り出す。アプリAとアプリCのアクセス比率は上述と同一で9対1である。
・未決定キュー:アプリD
・決定済アプリ群:アプリA、アプリC
・決定済アプリ群:アプリA、アプリC
つぎに、未決定キューからアプリDが取り出され、アプリDの優先度が決定済アプリ群のアプリAの優先度と同一であるか否かが判断される。ここでは、アプリDの優先度とアプリAの優先度が同一でないと判断される。
そして、CPU#0が、アプリAのアクセス回数とアプリDのアクセス回数とを比較して、アプリDのアクセス回数がアプリAのアクセス回数以上であるか否かを判断する。アプリAのアクセス回数もアプリDのアクセス回数も90であるため、アプリDのアクセス回数がアプリAのアクセス回数以上であると判断される。そして、CPU#0が、アプリAとアプリDとのアクセス比率をアプリAの優先度対アプリDの優先度に決定する。すなわち、アプリAとアプリDとのアクセス比率が下記のように決定される。
・アプリAとアプリDとのアクセス比率=90:30
=3:1
=3:1
CPU#0が、調停回路102へアプリAとアプリDとのアクセス比率を通知し、決定済アプリ群にアプリDを入れる。
・未決定キュー:φ
・決定済アプリ群:アプリA、アプリC、アプリD
・決定済アプリ群:アプリA、アプリC、アプリD
未決定キューがφ(空)であるため、CPU#0は、各CPUに割り当てられたすべてのアプリのアクセス比率を決定したと判断する。
図10は、アクセス比率に応じてマルチコアプロセッサから共有メモリ103へのアクセスを調停する例を示す説明図(その3)である。調停回路102はアクセス比率の通知を受け付けると、調停回路102がアプリAのアクセス要求をリクエストバッファ600へ3つ登録すると、アプリDのアクセス要求を1つ登録し、さらに、アプリAのアクセス要求を3つ登録する。そして、アプリDのアクセス要求を1つ登録し、調停回路102がアプリAのアクセス要求を3つ登録するとアプリAのアクセス要求がすでに9つ登録されているため、アプリCのアクセス要求を1つ登録する。
すなわち、アプリAとアプリDのアクセス比率が3対1であるため、リクエストバッファ600へアプリAのアクセス要求が3つ登録される都度、アプリDのアクセス要求が1つ登録される。また、アプリAとアプリCのアクセス比率が9対1であるため、リクエストバッファ600へアプリAのアクセス要求が9つ登録される都度、アプリCのアクセス要求が1つ登録される。
図11は、CPU#0でアプリAからアプリEへのタスクスイッチが発生した例を示す説明図である。CPU#0にアプリAが割り当てられていたが、タスクスイッチによりCPU#0にアプリEが割り当てられている。CPU#0が、該タスクスイッチを検出し、マルチコアプロセッサの各CPUに割り当てられたアプリケーションを特定して実行アプリ群とする。ここでは、実行アプリ群が下記である。
・実行アプリ群:アプリE、アプリD、アプリC
つぎに、CPU#0が、実行アプリ群の各アプリケーションのタグ情報(優先度とアクセス回数)を取得し、優先度が高い順にソートして未決定キューに入れる。すなわち、未決定キューの先頭に入っているアプリが各CPUに割り当てられたアプリケーションの中で優先度が最も高いアプリケーションである。未決定キューは下記の様になる。
・未決定キュー:アプリC→アプリD→アプリE
・決定済アプリ群:φ
・決定済アプリ群:φ
そして、CPU#0が、未決定キューの先頭からアプリを取り出し、取り出したアプリを未決定キューから削除し、取り出したアプリを決定済アプリ群に入れる。
・未決定キュー:アプリD→アプリE
・決定済アプリ群:アプリC
・決定済アプリ群:アプリC
つぎに、CPU#0が、未決定キューから先頭のアプリDを取り出し、取り出したアプリを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリであるアプリCを取り出す。CPU#0が、アプリCの優先度とアプリDの優先度とを比較して等しいか否かを判断する。アプリCの優先度とアプリDの優先度は等しくないと判断される。
CPU#0が、アプリDのアクセス回数がアプリCのアクセス回数以上であるか否かを判断する。アプリDのアクセス回数が90であり、アプリCのアクセス回数が80であるため、アプリDのアクセス回数がアプリCのアクセス回数以上であると判断される。そして、アプリDのアクセス回数がアプリCのアクセス回数以上であると判断されると、CPU#0が、アプリCとアプリDとのアクセス比率をアプリCの優先度対アプリDの優先度に決定する。すなわち、アプリCとアプリDが重み付けラウンドロビン方式で制御され、アプリCとアプリDとのアクセス比率が下記のように決定される。
・アプリCとアプリDとのアクセス比率=アプリCの優先度:アプリDの優先度
=40:30
=4:3
=40:30
=4:3
そして、CPU#0が、決定したアクセス比率を調停回路102へ通知し、アプリDを決定済アプリ群に入れる。
・未決定キュー:アプリE
・決定済アプリ群:アプリC、アプリD
・決定済アプリ群:アプリC、アプリD
つぎに、CPU#0が、未決定キューが空でないため、未決定キューから先頭のアプリEを取り出し、取り出したアプリEを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリであるアプリCを取り出す。CPU#0が、アプリCの優先度とアプリEの優先度とを比較して等しいか否かを判断する。ここでは、アプリCの優先度とアプリEの優先度は等しくないと判断される。
CPU#0が、アプリEのアクセス回数がアプリCのアクセス回数以上であるか否かを判断する。アプリEのアクセス回数が10であり、アプリCのアクセス回数が80であるため、アプリEのアクセス回数がアプリCのアクセス回数未満であると判断される。そして、アプリDのアクセス回数がアプリCのアクセス回数未満であると判断されると、CPU#0が、アプリCとアプリEとのアクセス比率を9対1に決定する。すなわち、優先度制御方式で制御される。CPU#0が、決定したアクセス比率を調停回路102へ通知し、アプリEを決定済アプリ群に入れる。
・未決定キュー:φ
・決定済アプリ群:アプリC、アプリD、アプリE
・決定済アプリ群:アプリC、アプリD、アプリE
未決定キューがφ(空)であるため、CPU#0は、各CPUに割り当てられたすべてのアプリのアクセス比率を決定したと判断する。
図12は、アクセス比率に応じてマルチコアプロセッサから共有メモリ103へのアクセスを調停する例を示す説明図(その4)である。調停回路102はアクセス比率の通知を受け付けると、調停回路102がアプリCのアクセス要求をリクエストバッファ600へ4つ登録すると、アプリDのアクセス要求を3つ登録し、さらに、アプリCのアクセス要求を4つ登録する。そして、アプリDのアクセス要求を3つ登録し、調停回路102がアプリCのアクセス要求を1つ登録するとアプリCのアクセス要求をすでに9つ登録しているため、アプリEのアクセス要求を1つ登録する。
すなわち、アプリCとアプリDのアクセス比率が4対3であるため、リクエストバッファ600へアプリCのアクセス要求が4つ登録される都度、アプリDのアクセス要求が3つ登録される。アプリCとアプリEのアクセス比率が9対1であるため、リクエストバッファ600へアプリCのアクセス要求が9つ登録される都度、アプリEのアクセス要求が1つ登録される。
図13は、CPU#0でアプリEからアプリGへのタスクスイッチおよびCPU#2でアプリCからアプリFへのタスクスイッチが発生した例を示す説明図である。CPU#0にアプリEが割り当てられていたが、タスクスイッチによりCPU#0にアプリGが割り当てられている。さらに、CPU#2にアプリCが割り当てられていたが、タスクスイッチによりCPU#2にアプリFが割り当てられている。CPU#0が、2つのタスクスイッチを検出し、マルチコアプロセッサの各CPUに割り当てられたアプリケーションを特定して実行アプリ群とする。ここでは、実行アプリ群が下記である。
・実行アプリ群:アプリD、アプリF、アプリG
つぎに、CPU#0が、実行アプリ群の各アプリケーションのタグ情報(優先度とアクセス回数)を取得し、優先度が高い順にソートして未決定キューに入れる。
・未決定キュー:アプリD→アプリF→アプリG
・決定済アプリ群:φ
・決定済アプリ群:φ
そして、CPU#0が、未決定キューの先頭からアプリDを取り出し、取り出したアプリDを未決定キューから削除し、取り出したアプリDを決定済アプリ群に入れる。
・未決定キュー:アプリF→アプリG
・決定済アプリ群:アプリD
・決定済アプリ群:アプリD
つぎに、CPU#0が、未決定キューから先頭のアプリFを取り出し、取り出したアプリFを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリDを取り出す。CPU#0が、アプリDの優先度とアプリFの優先度とを比較して等しいか否かを判断する。アプリDの優先度とアプリFの優先度は等しいと判断される。
CPU#0が、アプリDのアクセス回数とアプリFのアクセス回数が等しいか否かを判断する。アプリDのアクセス回数が90回であり、アプリFのアクセス回数が30回であるため、アプリDのアクセス回数とアプリFのアクセス回数が等しくないと判断される。そして、アプリDのアクセス回数とアプリFのアクセス回数が等しくないと判断されると、CPU#0が、アプリDとアプリFとのアクセス比率をアプリDのアクセス回数対アプリFのアクセス回数に決定する。すなわち、アプリDとアプリFが重み付けラウンドロビン方式で制御され、アプリDとアプリFとのアクセス比率が下記のように決定される。
・アプリDとアプリFとのアクセス比率=アプリDのアクセス回数:アプリFのアクセス回数
=90:30
=3:1
=90:30
=3:1
そして、CPU#0が、決定したアクセス比率を調停回路102へ通知し、アプリFを決定済アプリ群に入れる。
・未決定キュー:アプリG
・決定済アプリ群:アプリD、アプリF
・決定済アプリ群:アプリD、アプリF
つぎに、CPU#0が、未決定キューが空でないため、未決定キューから先頭のアプリGを取り出し、取り出したアプリGを未決定キューから削除する。そして、CPU#0が、決定済アプリ群の中で最も優先度が高いアプリであるアプリケーションを取り出す。ここでは、アプリDの優先度とアプリFの優先度は同一であるが、アプリDが取り出されることとする。CPU#0が、アプリDの優先度とアプリGの優先度とを比較して等しいか否かを判断する。ここでは、アプリDの優先度とアプリGの優先度は等しいと判断される。
CPU#0が、アプリDのアクセス回数とアプリGのアクセス回数が等しいか否かを判断する。アプリDのアクセス回数が90であり、アプリGのアクセス回数が90であるため、アプリDのアクセス回数とアプリGのアクセス回数が等しいと判断される。そして、アプリDのアクセス回数とアプリGのアクセス回数が等しいと判断されると、CPU#0が、アプリDとアプリGとのアクセス比率を1対1に決定する。すなわち、アプリDとアプリFがラウンドロビン方式で制御される。CPU#0が、決定したアクセス比率を調停回路102へ通知し、アプリGを決定済アプリ群に入れる。
・未決定キュー:φ
・決定済アプリ群:アプリD、アプリF、アプリG
・決定済アプリ群:アプリD、アプリF、アプリG
未決定キューがφ(空)であるため、CPU#0は、各CPUに割り当てられたすべてのアプリのアクセス比率を決定したと判断する。
図14は、アクセス比率に応じてマルチコアプロセッサから共有メモリ103へのアクセスを調停する例を示す説明図(その5)である。調停回路102はアクセス比率の通知を受け付けると、調停回路102がアプリDのアクセス要求をリクエストバッファ600へ1つ登録すると、アプリGのアクセス要求を1つ登録し、さらに、アプリDのアクセス要求を1つ登録する。そして、アプリGのアクセス要求を1つ登録し、調停回路102がアプリDのアクセス要求を1つ登録するとアプリDのアクセス要求をすでに3つ登録しているため、アプリFのアクセス要求を1つ登録する。
すなわち、アプリDとアプリFのアクセス比率が3対1であるため、リクエストバッファ600へアプリDのアクセス要求が3つ登録される都度、アプリFのアクセス要求が1つ登録される。また、アプリDとアプリGのアクセス比率が1対1であるため、リクエストバッファ600へアプリDのアクセス要求が1つ登録される都度、アプリGのアクセス要求が1つ登録される。
(マルチコアプロセッサでの制御処理手順)
図15および図16は、マルチコアプロセッサでの制御処理手順を示すフローチャートである。まず、CPU#0が、検出部301により、タスクディスパッチまたはタスクスイッチを検出したか否かを判断する(ステップS1501)。CPU#0が、タスクディスパッチまたはタスクスイッチを検出していないと判断した場合(ステップS1501:No)、ステップS1501へ戻る。
図15および図16は、マルチコアプロセッサでの制御処理手順を示すフローチャートである。まず、CPU#0が、検出部301により、タスクディスパッチまたはタスクスイッチを検出したか否かを判断する(ステップS1501)。CPU#0が、タスクディスパッチまたはタスクスイッチを検出していないと判断した場合(ステップS1501:No)、ステップS1501へ戻る。
一方、CPU#0が、タスクディスパッチまたはタスクスイッチを検出したと判断した場合(ステップS1501:Yes)、各CPUに割り当てられたアプリケーション(実行アプリ群)を特定する(ステップS1502)。つぎに、CPU#0が、特定したアプリケーションが一つか否かを判断する(ステップS1503)。
CPU#0が、特定したアプリケーションが一つであると判断した場合(ステップS1503:Yes)、決定部305により、特定したアプリケーションのアクセス比率を1に決定する(ステップS1504)。特定したアプリケーションが1つしかないため、特定したアプリケーションのアクセス比率を1にするとは、特定したアプリケーションAが割り当てられているCPUにのみアクセス権を与えることを指す。そして、CPU#0が、通知部306により、決定したアクセス比率を調停回路へ通知する(ステップS1505)。
つぎに、CPU#0が、特定したアプリケーションが一つでないと判断した場合(ステップS1503:No)、取得部302により、実行アプリ群の各アプリケーションの優先度およびアクセス回数を取得する(ステップS1506)。そして、CPU#0が、実行アプリ群を優先度の高い順にソートして未決定キューに挿入し(ステップS1507)、未決定キューから先頭に挿入されているアプリケーションを第1のアプリケーションとして取得する(ステップS1508)。つぎに、CPU#0が、未決定キューから第1のアプリケーションを削除する(ステップS1509)。
つぎに、CPU#0が、決定済アプリ群が空か否かを判断する(ステップS1510)。CPU#0が、決定済アプリ群が空でないと判断した場合(ステップS1510:No)、特定部303により、決定済アプリ群から最も優先度の高いアプリを第2のアプリケーションとして特定する(ステップS1511)。そして、CPU#0が、比較部304により、第1のアプリケーションの優先度が第2のアプリケーションの優先度と等しいか否かを判断する(ステップS1512)。
CPU#0が、第1のアプリケーションの優先度が第2のアプリケーションの優先度と等しくないと判断した場合(ステップS1512:No)、比較部304により、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数以上かを判断する(ステップS1513)。CPU#0が、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数以上でないと判断した場合(ステップS1513:No)、ステップS1515に移行する。一方、CPU#0が、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数以上であると判断した場合(ステップS1513:Yes)、ステップS1516に移行する。
ステップS1515において、CPU#0が、決定部305により、第2のアプリケーションと第1のアプリケーションとのアクセス比率を所定数対1に決定する(ステップS1515)。ステップS1516において、CPU#0が、決定部305により、第2のアプリケーションと第1のアプリケーションとのアクセス比率を第2のアプリケーションの優先度対第1のアプリケーションの優先度に決定する(ステップS1516)。
一方、ステップS1512において、CPU#0が、第1のアプリケーションの優先度が第2のアプリケーションの優先度と等しいと判断した場合(ステップS1512:Yes)、ステップS1514に移行する。ステップS1514では、CPU#0が、比較部304により、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数と等しいか否かを判断する(ステップS1514)。
CPU#0が、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数と等しいと判断した場合(ステップS1514:Yes)、ステップS1517へ移行する。一方、CPU#0が、第1のアプリケーションのアクセス回数が第2のアプリケーションのアクセス回数と等しくないと判断した場合(ステップS1514:No)、ステップS1518に移行する。
ステップS1517において、CPU#0が、決定部305により、アプリケーションAとアプリケーションBとのアクセス比率を1対1に決定する(ステップS1517)。ステップS1518において、CPU#0が、決定部305により、アプリケーションAとアプリケーションBとのアクセス比率を第2のアプリケーションのアクセス回数対第1のアプリケーションのアクセス回数に決定する(ステップS1518)。
ステップS1515、ステップS1516、ステップS1517、またはステップS1518のつぎに、CPU#0が、通知部306により、決定したアクセス比率を調停回路へ通知し(ステップS1519)、ステップS1520へ移行する。
ステップS1519のつぎに、またはステップS1510において、CPU#0が、決定済アプリ群が空であると判断した場合(ステップS1510:Yes)、第1のアプリケーションを決定済アプリ群に登録する(ステップS1520)。そして、CPU#0が、未決定キューが空か否かを判断し(ステップS1521)、未決定キューが空であると判断した場合(ステップS1521:Yes)、決定済アプリ群を空に設定し(ステップS1524)、ステップS1501へ戻る。
一方、CPU#0が、未決定キューが空でないと判断した場合(ステップS1521:No)、タスクディスパッチまたはタスクスイッチを検出したか否かを判断する(ステップS1522)。CPU#0が、タスクディスパッチまたはタスクスイッチを検出していないと判断した場合(ステップS1522:No)、ステップS1508へ戻る。一方、CPU#0が、タスクディスパッチまたはタスクスイッチを検出したと判断した場合(ステップS1522:Yes)、決定済アプリ群および未決定キューを空に設定し(ステップS1523)、ステップS1502へ戻る。
以上説明したように、マルチコアプロセッサシステム、制御プログラム、および制御方法によれば、タスクスイッチまたはタスクディスパッチが検出される都度、各CPUに割り当てられたアプリケーションのうち最も優先度の高いアプリケーションを除く残余のアプリケーションと該最も優先度の高いアプリケーションとのアクセス比率とをアクセス回数に基づいて決定する。これにより、割り当てられたアプリケーションに沿って最適なアクセス比率でマルチコアプロセッサから共有資源へのアクセスを調停させることができる。
また、アプリケーションの優先度およびアクセス回数が最も優先度の高いアプリケーションの優先度およびアクセス回数と等しい場合、最も優先度が高いアプリケーションと該アプリケーションとのアクセス比率を1対1に決定する。すなわち、最も優先度が高いアプリケーションと該アプリケーションとがラウンドロビン方式で制御される。これにより、共有資源へのアクセスが均等に許可され、各アプリケーションのアクセス待ちの時間が均一化され、アクセス待ち時間に起因してアプリケーションの処理が遅くなることを防止できる。
また、アプリケーションの優先度が最も優先度の高いアプリケーションの優先度と等しく、該アプリケーションのアクセス回数が最も優先度の高いアプリケーションのアクセス回数と等しくない場合、最も優先度が高いアプリケーションのアクセス回数対該アプリケーションのアクセス回数をアクセス比率に決定する。すなわち、最も優先度が高いアプリケーションと該アプリケーションとがアクセス回数に基づく重み付けラウンドロビン方式で制御される。これにより、共有資源へのアクセス回数が多いアプリケーションのアクセス待ちの時間を減少させることで該アプリケーションの処理を高速化することができる。
また、最も優先度の高いアプリケーションの優先度よりも優先度が低いアプリケーションにおいて、該アプリケーションのアクセス回数が最も優先度の高いアプリケーションのアクセス回数以上の場合、最も優先度の高いアプリケーションの優先度対該アプリケーションの優先度をアクセス比率に決定する。すなわち、最も優先度が高いアプリケーションと該アプリケーションとが優先度に基づく重み付けラウンドロビン方式で制御される。これにより、アクセス回数が多くかつ優先度が高いアプリケーションのアクセスを優先的に終了させることができ、アクセス待ちの時間を減少させることで、アクセス回数が多くかつ優先度が高いアプリケーションの処理を高速化することができる。
また、最も優先度の高いアプリケーションの優先度よりも優先度が低いアプリケーションにおいて、該低いアプリケーションのアクセス回数が最も優先度の高いアプリケーションのアクセス回数未満の場合、最も優先度の高いアプリケーションと該低いアプリケーションとのアクセス比率を指定数対1に決定する。すなわち、最も優先度が高いアプリケーションと該アプリケーションとが優先度制御方式で制御される。これにより、優先度が高いアプリケーションのアクセスを優先的に終了させることができる。
100 マルチコアプロセッサシステム
301 検出部
302 取得部
304 比較部
305 決定部
306 通知部
301 検出部
302 取得部
304 比較部
305 決定部
306 通知部
Claims (7)
- マルチコアプロセッサにおいてアプリケーションの切り替え処理または割り当て処理を検出する検出手段と、
前記検出手段により前記切り替え処理または前記割り当て処理が検出された場合、前記マルチコアプロセッサの各コアに割り当てられたアプリケーションの実行に関する優先度および前記マルチコアプロセッサが共有する共有資源へのアクセス回数を取得する取得手段と、
前記割り当てられたアプリケーションのうち、前記取得手段により取得された優先度が最も高いアプリケーションを除く残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較することにより、前記優先度が最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を決定する決定手段と、
前記決定手段により決定されたアクセス比率を調停回路へ通知する通知手段と、
前記アクセス比率に基づいて、前記マルチコアプロセッサから前記共有資源へのアクセスを前記調停回路で調停する調停手段と、
を備えることを特徴とするマルチコアプロセッサシステム。 - 前記割り当てられたアプリケーションのうち、前記最も高いアプリケーションを除く残余のアプリケーションごとに前記残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較し、前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいか否かを判断する比較手段と、を備え、
前記決定手段は、
前記比較手段により前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいと判断され、かつ前記最も高いアプリケーションのアクセス回数と前記残余のアプリケーションのアクセス回数が等しいと判断された場合、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を1対1に決定することを特徴とする請求項1に記載のマルチコアプロセッサシステム。 - 前記割り当てられたアプリケーションのうち、前記最も高いアプリケーションを除く残余のアプリケーションごとに前記残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較し、前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいか否かを判断する比較手段と、を備え、
前記決定手段は、
前記比較手段により前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいと判断され、かつ前記最も高いアプリケーションのアクセス回数と前記残余のアプリケーションのアクセス回数が等しくないと判断された場合、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を前記最も高いアプリケーションのアクセス回数対前記残余のアプリケーションのアクセス回数に決定することを特徴とする請求項1に記載のマルチコアプロセッサシステム。 - 前記割り当てられたアプリケーションのうち、前記最も高いアプリケーションを除く残余のアプリケーションごとに前記残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較し、前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいか否かを判断する比較手段と、を備え、
前記決定手段は、
前記比較手段により前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しくないと判断され、かつ前記残余のアプリケーションのアクセス回数が前記最も高いアプリケーションのアクセス回数以上であると判断された場合において、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を前記最も高いアプリケーションの優先度対前記残余のアプリケーションの優先度に決定することを特徴とする請求項1に記載のマルチコアプロセッサシステム。 - 前記割り当てられたアプリケーションのうち、前記最も高いアプリケーションを除く残余のアプリケーションごとに前記残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較し、前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しいか否かを判断する比較手段と、を備え、
前記決定手段は、
前記比較手段により前記最も高いアプリケーションの優先度と前記残余のアプリケーションの優先度が等しくないと判断され、かつ前記残余のアプリケーションのアクセス回数が前記最も高いアプリケーションのアクセス回数未満であると判断された場合、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を所定数対1に決定することを特徴とする請求項1に記載のマルチコアプロセッサシステム。 - マルチコアプロセッサから該マルチコアプロセッサが共有する共有資源へのアクセスをアクセス比率に応じて調停する調停回路を制御する前記マルチコアプロセッサの一のコアに、
前記マルチコアプロセッサにおいてアプリケーションの切り替え処理または割り当て処理を検出する検出工程と、
前記検出工程により前記切り替え処理または前記割り当て処理が検出された場合、前記マルチコアプロセッサの各コアに割り当てられたアプリケーションの実行に関する優先度および前記共有資源へのアクセス回数を取得する取得工程と、
前記割り当てられたアプリケーションのうち、前記取得工程により取得された優先度が最も高いアプリケーションを除く残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較することにより、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を決定する決定工程と、
前記決定工程により決定されたアクセス比率を前記調停回路へ通知する通知工程と、
を実行させることを特徴とする制御プログラム。 - マルチコアプロセッサから該マルチコアプロセッサが共有する共有資源へのアクセスをアクセス比率に応じて調停する調停回路を制御する前記マルチコアプロセッサの一のコアが、
前記マルチコアプロセッサにおいてアプリケーションの切り替え処理または割り当て処理を検出する検出工程と、
前記検出工程により前記切り替え処理または前記割り当て処理が検出された場合、前記マルチコアプロセッサの各コアに割り当てられたアプリケーションの実行に関する優先度および前記共有資源へのアクセス回数を取得する取得工程と、
前記割り当てられたアプリケーションのうち、前記取得工程により取得された優先度が最も高いアプリケーションを除く残余のアプリケーションのアクセス回数と前記最も高いアプリケーションのアクセス回数とを比較することにより、前記最も高いアプリケーションと前記残余のアプリケーションとのアクセス比率を決定する決定工程と、
を実行することを特徴とする制御方法。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2010/054885 WO2011114533A1 (ja) | 2010-03-19 | 2010-03-19 | マルチコアプロセッサシステム、制御プログラム、および制御方法 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2013171948A Division JP5605477B2 (ja) | 2013-08-22 | 2013-08-22 | マルチコアプロセッサシステム、制御プログラム、および制御方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPWO2011114533A1 JPWO2011114533A1 (ja) | 2013-06-27 |
JP5348315B2 true JP5348315B2 (ja) | 2013-11-20 |
Family
ID=44648659
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012505430A Expired - Fee Related JP5348315B2 (ja) | 2010-03-19 | 2010-03-19 | マルチコアプロセッサシステム、制御プログラム、および制御方法 |
Country Status (3)
Country | Link |
---|---|
US (1) | US9092273B2 (ja) |
JP (1) | JP5348315B2 (ja) |
WO (1) | WO2011114533A1 (ja) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8959263B2 (en) * | 2013-01-08 | 2015-02-17 | Apple Inc. | Maintaining I/O priority and I/O sorting |
US9772959B2 (en) | 2014-05-30 | 2017-09-26 | Apple Inc. | I/O scheduling |
CN111090509B (zh) * | 2019-12-06 | 2023-08-11 | 深圳震有科技股份有限公司 | 一种mdio资源的访问方法、存储介质及智能终端 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH02143363A (ja) * | 1988-11-24 | 1990-06-01 | Fujitsu Ltd | マルチプロセッサ装置における共通メモリ制御方法 |
JPH08153023A (ja) * | 1994-11-30 | 1996-06-11 | Toshiba Corp | 命令実行頻度計測方法、及び同方法を用いたマルチプロセッサシステム |
JPH10240698A (ja) * | 1997-02-24 | 1998-09-11 | Nec Corp | 高負荷ジョブ負荷分散方式 |
JP2003006170A (ja) * | 2001-06-20 | 2003-01-10 | Hitachi Ltd | 複数計算機環境でのプログラム実行方法 |
JP2007018268A (ja) * | 2005-07-07 | 2007-01-25 | Sumitomo Heavy Ind Ltd | タスクスケジューリング方法、タスクスケジューリング装置、及びタスクスケジューリングプログラム |
JP2008158687A (ja) * | 2006-12-21 | 2008-07-10 | Toshiba Corp | 帯域制御プログラム及びマルチプロセッサシステム |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5067088B2 (ja) | 2007-09-13 | 2012-11-07 | 富士ゼロックス株式会社 | 制御装置、プログラム、画像形成装置、および情報処理装置 |
US7996346B2 (en) | 2007-12-19 | 2011-08-09 | International Business Machines Corporation | Method for autonomic workload distribution on a multicore processor |
-
2010
- 2010-03-19 JP JP2012505430A patent/JP5348315B2/ja not_active Expired - Fee Related
- 2010-03-19 WO PCT/JP2010/054885 patent/WO2011114533A1/ja active Application Filing
-
2012
- 2012-09-13 US US13/614,097 patent/US9092273B2/en not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH02143363A (ja) * | 1988-11-24 | 1990-06-01 | Fujitsu Ltd | マルチプロセッサ装置における共通メモリ制御方法 |
JPH08153023A (ja) * | 1994-11-30 | 1996-06-11 | Toshiba Corp | 命令実行頻度計測方法、及び同方法を用いたマルチプロセッサシステム |
JPH10240698A (ja) * | 1997-02-24 | 1998-09-11 | Nec Corp | 高負荷ジョブ負荷分散方式 |
JP2003006170A (ja) * | 2001-06-20 | 2003-01-10 | Hitachi Ltd | 複数計算機環境でのプログラム実行方法 |
JP2007018268A (ja) * | 2005-07-07 | 2007-01-25 | Sumitomo Heavy Ind Ltd | タスクスケジューリング方法、タスクスケジューリング装置、及びタスクスケジューリングプログラム |
JP2008158687A (ja) * | 2006-12-21 | 2008-07-10 | Toshiba Corp | 帯域制御プログラム及びマルチプロセッサシステム |
Also Published As
Publication number | Publication date |
---|---|
US20130013835A1 (en) | 2013-01-10 |
US9092273B2 (en) | 2015-07-28 |
JPWO2011114533A1 (ja) | 2013-06-27 |
WO2011114533A1 (ja) | 2011-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6437579B2 (ja) | 仮想化環境におけるインテリジェントgpuスケジューリング | |
JP2005056391A (ja) | コンピューティング環境の作業負荷を均衡させる方法およびシステム | |
US9513965B1 (en) | Data processing system and scheduling method | |
JPWO2008062864A1 (ja) | 仮想マシン配置システム、仮想マシン配置方法、プログラム、仮想マシン管理装置およびサーバ装置 | |
JPH04328665A (ja) | マルチプロセッサ・システム | |
US8892819B2 (en) | Multi-core system and external input/output bus control method | |
TW202246977A (zh) | 一種任務調度方法、任務調度裝置、電腦設備、電腦可讀儲存媒介和電腦程式產品 | |
JP6201591B2 (ja) | 情報処理装置および情報処理装置の制御方法 | |
JP5348315B2 (ja) | マルチコアプロセッサシステム、制御プログラム、および制御方法 | |
US20060184942A1 (en) | System, method and medium for using and/or providing operating system information to acquire a hybrid user/operating system lock | |
JP5605477B2 (ja) | マルチコアプロセッサシステム、制御プログラム、および制御方法 | |
US20130298132A1 (en) | Multi-core processor system and scheduling method | |
JP5429363B2 (ja) | マルチコアプロセッサシステム、制御プログラム、および制御方法 | |
JP5915706B2 (ja) | 調停回路、制御方法、および制御プログラム | |
KR20130112180A (ko) | 모바일 멀티코어 가상화 시스템에서 실시간 처리를 보장하기 위한 스케쥴링 방법 | |
JP2013047892A (ja) | 情報処理装置、スケジューリング方法およびプログラム | |
JP5704176B2 (ja) | プロセッサ処理方法、およびプロセッサシステム | |
JPH0877026A (ja) | 情報処理方法とその装置 | |
JP5713091B2 (ja) | マルチコアプロセッサシステム、制御方法、および制御プログラム | |
KR20130094889A (ko) | 실시간 운영체제의 태스크 스케줄링 방법 | |
Blagodurov et al. | In search for contention-descriptive metrics in HPC cluster environment | |
Nadeem et al. | Bandwidth Stealing TDMA Arbitration for Real-Time Multiprocessor Applications | |
JP5494925B2 (ja) | 半導体集積回路、情報処理装置およびプロセッサ性能保証方法 | |
Madheswari et al. | Static and dynamic job scheduling with communication aware policy in cluster computing | |
JP2009181554A (ja) | 計算機システム、性能情報取得方法、および性能情報取得プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130723 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130805 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |