WO2012101759A1 - プロセッサ処理方法、およびプロセッサシステム - Google Patents

プロセッサ処理方法、およびプロセッサシステム Download PDF

Info

Publication number
WO2012101759A1
WO2012101759A1 PCT/JP2011/051353 JP2011051353W WO2012101759A1 WO 2012101759 A1 WO2012101759 A1 WO 2012101759A1 JP 2011051353 W JP2011051353 W JP 2011051353W WO 2012101759 A1 WO2012101759 A1 WO 2012101759A1
Authority
WO
WIPO (PCT)
Prior art keywords
cpu
application
access
memory controller
memory
Prior art date
Application number
PCT/JP2011/051353
Other languages
English (en)
French (fr)
Inventor
宏真 山内
浩一郎 山下
鈴木 貴久
康志 栗原
早川 文彦
俊也 大友
Original Assignee
富士通株式会社
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to JP2012554531A priority Critical patent/JP5704176B2/ja
Priority to PCT/JP2011/051353 priority patent/WO2012101759A1/ja
Publication of WO2012101759A1 publication Critical patent/WO2012101759A1/ja
Priority to US13/949,922 priority patent/US20130318310A1/en

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023Failover techniques
    • G06F11/203Failover techniques using migration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0721Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU]
    • G06F11/0724Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment within a central processing unit [CPU] in a multiprocessor or a multi-core unit
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751Error or fault detection not based on redundancy
    • G06F11/0754Error or fault detection not based on redundancy by exceeding limits
    • G06F11/076Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3471Address tracing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3476Data logging

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)
  • Hardware Redundancy (AREA)

Abstract

 メモリコントローラが、マルチコアプロセッサのうちのCPU(#0)で実行中のアプリ(#0)からマルチコアプロセッサの各CPUで共有する共有メモリへのアクセスの傾向情報が許容範囲内であるか否かを判断する。アクセスの傾向情報が所定許容範囲内でない場合、アプリ(#0)またはCPU(#0)の処理が通常の処理と異なる処理を行っている可能性があるため、アプリ(#0)またはCPU(#0)がエラー状態である可能性がある。メモリコントローラが、アクセスの傾向情報が所定許容範囲内でないと判断した場合、CPU(#0)に割当済のアプリ(#0)を除く他のアプリケーションアプリ(#2)をCPU(#0)からCPU(#1)に移行させる移行処理を制御する。アプリ(#0)またはCPU(#0)のエラーによる影響がアプリ(#2)に波及するのを防止できる。

Description

プロセッサ処理方法、およびプロセッサシステム
 本発明は、共有資源へのアクセスを制御するプロセッサ処理方法、およびプロセッサシステムに関する。
 従来、マルチコアプロセッサシステムには、共有メモリアーキテクチャと分散メモリアーキテクチャとの2種類がある。共有メモリアーキテクチャでは、マルチコアプロセッサの複数のCPU(Central Processing Unit)でメインメモリが共有される。分散メモリアーキテクチャでは、マルチコアプロセッサの各CPUにメインメモリが備えられている。組み込みシステムにおいては低コストで実装できる共有メモリアーキテクチャが主に用いられる。
 共有メモリアーキテクチャでは、各CPUでそれぞれアプリケーションを実行している状態において、2つのCPUからメモリへのアクセスリクエストがコンフリクトすると、一方のCPUはメモリへのアクセスを待ち、他方のCPUはメモリにアクセスする。さらに、他方のCPUが膨大な回数のメモリアクセスを行っている場合、一方のCPUが待機し続けなければならない。そこで、各CPUからのメモリアクセス回数をカウントし、所定回数を超えた場合に、メモリアクセスを制限する技術が知られている(たとえば、下記特許文献1,2を参照。)。
 また、1CPU上でアプリケーションの実行によって障害が発生し、無限に共有メモリへのアクセスを行う状況となると、1CPU上でアプリケーションの実行によってバグが発生した場合、無限に共有メモリへのアクセスを行うことがある。そこで、各CPUが、該CPUに割り当てられたアプリケーションの実行時間に基づいてアプリケーションの実行に障害が発生したか否かを判断する技術(従来技術1)が知られている(たとえば、下記特許文献3を参照。)。
 さらに、共有メモリアーキテクチャにおいて、複数のCPUが接続されるバス調停回路が各CPUから送信される信号に基づいてエラー状態であるCPUを特定する技術(従来技術2)が知られている(たとえば、下記特許文献4,5を参照。)。
特開平9-282252号公報 特開2004-133496号公報 特開2006-202076号公報 特開2004-171072号公報 特開平6-124248号公報
 しかしながら、従来技術1では、アプリケーションの割当先CPUがエラー状態である影響で、アプリケーションの実行時間が長くなる場合、あらたに割当先CPUに割り当てられるアプリケーションもすべてエラーとなってしまう問題点があった。また、割当先CPUに複数のアプリケーションが割り当てられている場合、それぞれの実行時間は長くなる。
 また、従来技術2では、バス調停回路によりエラーとなっているCPUを特定することはできるが、CPUに割り当てられているアプリケーションのエラーと共にエラーとなってしまう問題点があった。
 本発明は、上述した従来技術による問題点を解消するため、アプリケーションまたは該アプリケーションの割当先CPUのエラーの影響が他のアプリケーションに波及するのを防止することができるプロセッサ処理方法、およびプロセッサシステムを提供することを目的とする。また、本発明は、アプリケーションまたは該アプリケーションの割当先CPUのエラーの影響が他のCPUに波及するのを防止することができるプロセッサ処理方法、およびプロセッサシステムを提供することを目的とする。
 本発明の一の観点によれば、第1のCPUが実行中の第1アプリケーションが正常に動作しているか否かを第1アプリケーションの共有資源へのアクセスログに基づいて判断し、前記第1アプリケーションが正常動作していないと判断されたときに、前記第1のCPUによって実行される前記第1アプリケーション以外の第2アプリケーションを第2のCPUに実行させるプロセッサ処理方法、およびプロセッサシステムを提供する。
 本発明の他の観点によれば、第1のCPUが実行中の第1アプリケーションが正常に動作しているか否かを第1アプリケーションの共有資源へのアクセスログに基づいて判断し、前記第1アプリケーションが正常に動作していないと判断されたときに、前記第1アプリケーションのメモリアクセスの優先度を下げるプロセッサ処理方法、およびプロセッサシステムを提供する。
 本プロセッサ処理方法、およびプロセッサシステムによれば、アプリケーションまたは該アプリケーションの割当先CPUのエラーの影響が他のアプリケーションに波及するのを防止することができるという効果を奏する。また、本プロセッサ処理方法、およびプロセッサシステムによれば、アプリケーションまたは該アプリケーションの割当先CPUのエラーの影響が他のCPUに波及するのを防止することができるという効果を奏する。
図1は、本発明の一の例を示す説明図である。 図2は、本発明の他の例を示す説明図である。 図3は、アクセスの傾向の一の例を示す説明図である。 図4は、アクセスの傾向の他の例を示す説明図である。 図5は、マルチコアプロセッサシステムのハードウェアを示すブロック図である。 図6は、管理テーブルの一例を示す説明図である。 図7は、負荷情報の一例を示す説明図である。 図8は、メモリコントローラ509のブロック図を示す説明図である。 図9は、アクセス回数に関するアクセスログの一例を示す説明図である。 図10は、実施例1にかかるアクセスログ900の一例を示す説明図である。 図11は、アプリ#2が移行される例を示す説明図である。 図12は、ソフトウェアリセットの一例を示す説明図である。 図13は、ハードウェアリセットの一例を示す説明図である。 図14は、アクセス回数に関するアクセスログの更新処理の更新処理手順例を示すフローチャートである。 図15は、実施例1にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。 図16は、実施例1にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。 図17は、メモリコントローラ509がアクセスの比率を下げる例を示す説明図である。 図18は、実施例2でのアクセスログ900を示す説明図(その1)である。 図19は、実施例2でのアクセスログ900を示す説明図(その2)である。 図20は、実施例2にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。 図21は、実施例2にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。 図22は、メモリ番地に関するアクセスログの一例を示す説明図である。 図23は、実施例3でのアクセスログ2200を示す説明図である。 図24は、メモリ番地に関するアクセスログの更新処理の更新処理手順例を示すフローチャートである。 図25は、実施例4でのアクセスログを示す説明図(その1)である。 図26は、実施例4でのアクセスログを示す説明図(その2)である。
 以下に、本発明にかかるプロセッサ処理方法、およびプロセッサシステムの好適な実施の形態を詳細に説明する。ここでは、プロセッサシステムとして、マルチコアプロセッサシステムを例に挙げる。マルチコアプロセッサシステムにおいて、マルチコアプロセッサとはコアが複数搭載されたプロセッサである。コアが複数搭載されていれば、複数のコアが搭載された単一のプロセッサでもよく、シングルコアのプロセッサが並列されているプロセッサ群でもよい。なお、本実施の形態では、説明を単純化するため、シングルコアのプロセッサが並列されているプロセッサ群を例に挙げて説明する。
 また、本実施の形態では、マルチコアプロセッサの各CPUに共有される共有資源として共有メモリを例に挙げ、メモリコントローラがプロセッサ処理方法の各工程を実行する処理を例に挙げて説明する。CPUが本実施の形態で説明するプロセッサ処理を実行すると、該CPUに障害が発生している場合、該障害を検出することができない。そこで、周辺デバイスであり、マルチコアプロセッサで共有する共有メモリへのアクセスを制御するメモリコントローラが本実施の形態で説明するプロセッサ処理を行う。これにより、マルチコアプロセッサのうちのいずれのCPUに障害が発生しても該障害を検出することができる。また、メモリコントローラの障害については、各CPUが共有メモリへのアクセスリクエストを行うことで、検出することができる。
 図1は、本発明の一の例を示す説明図である。メモリコントローラが、CPU#0で実行中のアプリ#0からマルチコアプロセッサの各CPUで共有する共有メモリへのアクセスの傾向情報が許容範囲内であるか否かを判断する。
 メモリコントローラが、アクセスの傾向情報が許容範囲内でないと判断した場合、CPU#0に割当済のアプリ#0を除く他のアプリケーション(アプリ#2)を、CPU#0からマルチコアプロセッサのうちの他のCPUであるCPU#1に移行させる移行処理を制御する。
 図2は、本発明の他の例を示す説明図である。メモリコントローラが、マルチコアプロセッサのうちのCPU#0で実行中のアプリ#0からマルチコアプロセッサの各CPUで共有する共有メモリへのアクセスの傾向情報が許容範囲内であるか否かを判断する。メモリコントローラが、アクセスの傾向情報が許容範囲内でないと判断した場合、アプリ#0から共有メモリへのアクセスの比率を判断前よりも下げる。
 図3は、アクセスの傾向の一の例を示す説明図である。図3では、あるアプリケーションの正常動作時に、所定時間以内に何回共有メモリへアクセスするかを示している。たとえば、ブラウザアプリケーションであれば、共有メモリへ1秒間に10万回程度アクセスするなど、1秒間に何回程度共有メモリへアクセスするかはアプリケーションによってそれぞれ異なる。
 たとえば、あるアプリケーションの正常動作時には、所定時間内に共有メモリへ平均100~300回アクセスするとする。しかしながら、該アプリケーションを実行中の所定時間内に共有メモリへ500回アクセスしていれば(図中(a))、該アプリケーションがエラー状態である可能性がある。
 さらに、たとえば、該アプリケーションを実行中の所定時間内に共有メモリへアクセスしていなければ(アクセス回数が0回、図中(b))、該アプリケーションがハング状態である可能性がある。たとえば、平均値から±10[%]までのアクセス回数を許容範囲として、設計時に設計者が定義する。本実施の形態では、所定時間は、たとえば、一のタイマ割り込みから次のタイマ割り込みまでの時間である。
 図4は、アクセスの傾向の他の例を示す説明図である。図4では、あるアプリケーションの正常動作時に、所定時間以内に各メモリ番地に何回アクセスするかの傾向を示している。ここで、メモリ番地とは、論理アドレスを示している。図4では、あるアプリケーションが正常動作時にアクセスするメモリ番地が0x00000000FFFF~0x000FFFFFFFFFであることを示している。
 たとえば、該アプリケーションを実行中に、0x00000000FFFF~0x000FFFFFFFFF以外のメモリ番地(図中(a),(b))に何度もアクセスしていれば、該アプリケーションがエラーコードを読み出している可能性がある。すなわち、該アプリケーションがエラー状態である可能性がある。メモリ番地に関する許容範囲の定義については、後述する。
(マルチコアプロセッサシステムのハードウェア)
 図5は、マルチコアプロセッサシステムのハードウェアを示すブロック図である。マルチコアプロセッサシステム500は、CPU#0と、CPU#1と、CPU#2と、1次キャッシュ501と、1次キャッシュ502と、1次キャッシュ503と、スヌープ回路504と、2次キャッシュ505と、を有している。さらに、マルチコアプロセッサシステム500は、ディスプレイ506と、キーボード507と、I/F508(InterFace)と、メモリコントローラ509と、共有メモリ510と、PMU511と、タイマ517と、を有している。
 2次キャッシュ505と、I/F508と、メモリコントローラ509と、PMU511とは、バス518を介して接続されている。キーボード507と、ディスプレイ506と、共有メモリ510とは、メモリコントローラ509を介して各部と接続されている。
 まず、CPU#0とCPU#1とCPU#2とは、それぞれレジスタとコアとを有している。各レジスタには、PC(Program Counter)やリセットレジスタがある。リセットレジスタの値は通常0であり、1にセットされると該リセットレジスタを有するCPUのリセット処理が行われる。CPU#0はマスタCPUであり、マルチコアプロセッサシステム500の全体の制御を司り、OS(Operating System)521を実行する。
 OS521はマスタOSであり、アプリケーションをマルチコアプロセッサのうちのいずれのCPUに割り当てるかを制御する。さらに、OS521は該CPU#0に割り当てられたアプリケーションを実行する。OS521はスケジューラを有し、該スケジューラはCPU#0に割り当てられたアプリケーションを切り替えて実行する。
 CPU#1はスレーブCPUであり、OS522を実行する。OS522はスレーブOSであり、CPU#1に割り当てられたアプリケーションを実行する。OS522はスケジューラを有し、該スケジューラはCPU#1に割り当てられたアプリケーションを切り替えて実行する。
 CPU#2はスレーブCPUであり、OS523を実行する。OS523はスレーブOSであり、CPU#2に割り当てられたアプリケーションを実行する。OS523はスケジューラを有し、該スケジューラはCPU#2に割り当てられたアプリケーションを切り替えて実行する。
 OS521とOS522とOS523とは、それぞれレディーキュー531とレディーキュー532とレディーキュー533とを有している。各レディーキューには各CPUに割り当てられたアプリケーションのコンテキスト情報のポインタが積まれる。コンテキスト情報とは、たとえば、ロードされたアプリケーションの実行状態や該アプリケーション内の変数などが含まれる情報である。各OSはレディーキュー内のコンテキスト情報のポインタを取得し、アプリケーションのコンテキスト情報にアクセスすることで、アプリケーションを直ぐに実行することができる。
 ここでは、CPU#0にアプリ#2とアプリ#0が割り当てられ、アプリ#0が実行され、アプリ#2のコンテキスト情報のポインタがレディーキュー531に積まれている。CPU#1にはアプリ#1が割り当てられ、アプリ#1が実行されている。CPU#2にはアプリ#3が割り当てられ、アプリ#3が実行されている。
 CPU#0は、1次キャッシュ501とスヌープ回路504と2次キャッシュ505とを介して各部に接続されている。CPU#1は、1次キャッシュ502とスヌープ回路504と2次キャッシュ505とを介して各部に接続されている。CPU#2は、1次キャッシュ503とスヌープ回路504と2次キャッシュ505とを介して各部に接続されている。1次キャッシュ501と1次キャッシュ502と1次キャッシュ503とは、それぞれキャッシュメモリとキャッシュコントローラとを有している。
 1次キャッシュ501はOS521が実行するアプリケーションから共有メモリ510への書込処理を一時的に記憶する。1次キャッシュ501は、共有メモリ510から読み出されたデータを一時的に記憶する。また、1次キャッシュ502はOS522が実行するアプリケーションから共有メモリ510への書込処理を一時的に記憶する。1次キャッシュ502は、共有メモリ510から読み出されたデータを一時的に記憶する。また、1次キャッシュ503はOS523が実行するアプリケーションから共有メモリ510への書込処理を一時的に記憶する。1次キャッシュ503は、共有メモリ510から読み出されたデータを一時的に記憶する。
 スヌープ回路504は、1次キャッシュ501~1次キャッシュ503とで共有するデータがいずれかの1次キャッシュで更新された場合、該更新を検出し、他の1次キャッシュの該データも更新する。
 2次キャッシュ505は、キャッシュメモリとキャッシュコントローラとを有している。2次キャッシュ505では、1次キャッシュ501や1次キャッシュ502から追い出されたデータを記憶する。2次キャッシュ505では、OS521とOS522とで共有するデータを記憶する。2次キャッシュ505は、1次キャッシュ501や1次キャッシュ502よりも、記憶容量が大きくかつCPUからのアクセス速度が遅い。2次キャッシュ505は共有メモリ510より、記憶容量が小さくかつCPUからのアクセス速度が速い。
 ディスプレイ506は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。さらに、ディスプレイ506は、タッチパネルであり、数字、各種指示などの入力のためのキーを有し、データの入力を行ってもよい。ディスプレイ506は、たとえば、TFT液晶ディスプレイなどを採用することができる。
 キーボード507は、数字、各種指示などの入力のためのキーを有し、データの入力を行う。また、キーボード507は、タッチパネル式の入力パッドやテンキーなどであってもよい。
 I/F508は、通信回線を通じてLAN(Local Area Network)、WAN(Wide Area Network)、インターネットなどのネットワークに接続され、ネットワークを介して他の装置に接続される。そして、I/F508は、ネットワークと内部のインターフェースを司り、外部装置からのデータの入出力を制御する。I/F508には、たとえばモデムやLANアダプタなどを採用することができる。
 PMU511は各部に電源電圧を供給する。ここで、たとえば、PMU511は、各CPUやメモリコントローラ509からCPUの識別情報を受信すると、受信したCPUの識別情報に基づいて識別情報で示されるCPUの電源を遮断し、その後、再投入する機能を有する。これにより、該CPUはハードウェアリセットされる。タイマ517は、時刻をカウントし、所定時間ごとにメモリコントローラ509へ割り込みを行う(タイマ割り込み)。
 共有メモリ510は、CPU#0とCPU#1とCPU#2とに共有されるメモリであり、具体的には、たとえば、ROM(Read Only Memory)513と、RAM(Random Access Memory)512と、フラッシュROM514と、フラッシュROMコントローラ515と、フラッシュROM516と、などを有している。
 ROM513は、ブートシーケンスが記述されたブートローダなどのプログラムを記憶している。RAM512は、CPUのワークエリアとして使用される。フラッシュROM514は、OS521やOS522などのシステムソフトウェアやアプリケーションソフトウェアや後述する管理テーブルや負荷情報などを記憶している。たとえば、各OSを更新する場合、マルチコアプロセッサシステム500は、I/F508によって新しいOSを受信し、フラッシュROM514に格納されている古いOSを、受信した新しいOSに更新する。
 フラッシュROMコントローラ515は、各CPUの制御に従ってフラッシュROM516に対するデータのリード/ライトを制御する。フラッシュROM516は、フラッシュROMコントローラ515の制御で書き込まれたデータを記憶する。データの具体例としては、マルチコアプロセッサシステム500を使用するユーザがI/F508を通して取得した画像データ、映像データなどである。フラッシュROM516は、たとえば、メモリカード、SDカードなどを採用することができる。
 バス518は図示していないがバス調停回路を有し、バス調停回路は各部からのアクセスを調停する機能を有する。
 図6は、管理テーブルの一例を示す説明図である。管理テーブル600は、各CPUにいずれのアプリケーションが割り当てられているかを示す説明図である。管理テーブル600は、CPUの識別情報の項目601と、アプリケーションの識別情報の項目602とを有している。CPUの識別情報の項目601には各CPUの識別情報が登録されている。アプリケーションの識別情報の項目602には、CPUの識別情報の項目601に識別情報が登録されているCPUに割り当てられているアプリケーションの識別情報が登録される。
 管理テーブル600は、マスタCPUがアプリケーションをいずれかのCPUに割り当てる際にマスタCPUにより更新される。管理テーブル600は、各CPUがアプリケーションを他のCPUにマイグレーションする際に該CPUによって更新される。管理テーブル600は、割り当てられたアプリケーションを各CPUが終了する際に該CPUにより更新される。管理テーブル600は、共有メモリ510、各CPUの1次キャッシュ、2次キャッシュ505などの記憶装置に記憶されていることとする。
 図7は、負荷情報の一例を示す説明図である。負荷情報700は、アプリケーションの識別情報の項目701と、実行時間の項目702とを有している。アプリケーションの識別情報の項目701には、アプリケーションの識別情報が登録される。実行時間の項目702には、アプリケーションの識別情報の項目701に識別情報が登録されているアプリケーションの実行時間が登録される。
 ここでは、たとえば、メモリコントローラ509が、CPUごとに該CPUに割り当てられているアプリケーションの実行時間の合計値を負荷情報700に基づいて算出し、最も合計値が小さいCPUを最も負荷が小さいCPUとして特定する。負荷情報700は、共有メモリ510、各CPUの1次キャッシュ、2次キャッシュ505などの記憶装置に記憶されていることとする。
 図5に戻って、メモリコントローラ509は、たとえば、CPU#0とCPU#1からの共有メモリ510へのアクセスを調停する。図8を用いてメモリコントローラ509の詳細について説明する。
(メモリコントローラ509のブロック図)
 図8は、メモリコントローラ509のブロック図を示す説明図である。メモリコントローラ509は、リクエスト制御部801と、アクセスログ解析部802と、優先度変更部803と、最小負荷CPU特定部804と、メモリ制御部805と、I/O(Input/Output)制御部806と、を有している。リクエスト制御部801~I/O制御部806は、具体的には、たとえば、論理回路やFF(Flip Flop)などを用いて実現することができる。
 また、メモリコントローラ509がCPUや記憶装置を有し、リクエスト制御部801~I/O制御部806の処理がコーディングされたプログラムがメモリコントローラ509内の記憶装置に記憶されていることとしてもよい。そして、メモリコントローラ509内のCPUが該プログラムを読み出して、該プログラムにコーディングされている処理を実行することとしてもよい。該プログラムは、フラッシュROM516などのマルチコアプロセッサのいずれかのCPUが読み取り可能な記録媒体に記録され、マルチコアプロセッサのいずれかのCPUによって記録媒体から読み出されることによって実行されてもよい。また、該プログラムは、インターネット等のネットワークを介して配布されてもよい。
 リクエスト制御部801は、マルチコアプロセッサの各CPUからのメモリアクセスリクエストを受け付ける。さらに、リクエスト制御部801は、共有メモリ510から読み出したデータを各CPUに通知する。
 アクセスログ解析部802は、第1のCPUが実行中の第1アプリケーションが正常に動作しているか否かを第1アプリケーションのアクセスログに基づいて判断する。最小負荷CPU特定部804は、マルチコアプロセッサの中から、最小負荷のCPUを特定する。
 優先度変更部803は、対象アプリケーションが正常に動作していないと判断されたときに、対象アプリケーションから共有メモリ510へのアクセスの優先度を判断前よりも下げる。優先度変更部803は、前回のタイマ割り込みで対象アプリケーションが正常に動作していないと判断されたが、今回のタイマ割り込みで対象アプリケーションが正常に動作していると判断された場合、該アクセスの優先度を判断前よりも上げる。
 メモリ制御部805は、各CPUから受け付けたメモリアクセスリクエストに沿って、共有メモリ510にデータを書き込む。メモリ制御部805は、各CPUから受け付けたメモリアクセスリクエストに沿って、共有メモリ510からデータを読み出す。
 I/O制御部806は、ディスプレイ506やキーボード507などのI/Oデバイスへの出力や該I/Oデバイスからの入力を制御する。具体的には、たとえば、I/O制御部806は、キーボード507から入力されたデータをいずれのCPUへ通知するかを制御する。
 メモリコントローラ509による共有メモリ510へのアクセスについては、公知(たとえば、特開2005-276237参照。)であるため詳細な説明を省略する。
 つぎに、詳細な処理について、実施例1~4を用いて説明する。実施例1~2では、アクセスの傾向情報が共有メモリ510へのアクセス回数である場合について説明する。実施例3~4では、アクセスの傾向情報が共有メモリ510へのメモリ番地に関する情報である場合について説明する。
 また、実施例1~4では、タイマ517によるタイマ割り込みを検出する都度、各CPUに割当済のアプリケーションごとにアクセスログを解析することとする。そして、アクセスログに関しては、解析終了後にリセットする。
(実施例1)
 実施例1では、メモリコントローラ509がマルチコアプロセッサのうちの一のCPUで実行中の対象アプリケーションからマルチコアプロセッサの各CPUで共有する共有メモリ510へのアクセスの傾向情報が許容範囲内であるか否かを判断する。そして、実施例1では、アクセスの傾向情報が許容範囲内でないと判断された場合、一のCPUに割当済の対象アプリケーションを除く他のアプリケーションを、一のCPUからマルチコアプロセッサのうちの他のCPUに移行させる移行処理を制御する。アクセスの傾向情報は、アプリケーションごとにアクセスログとして共有メモリ510、各CPUの1次キャッシュ、2次キャッシュ505などの記憶装置に記憶されることとする。
 移行処理については、メモリコントローラ509が一のCPUから他のアプリケーションを他のCPUに移行させる移行指示を一のCPUに通知する。そして、一のCPUが他のアプリケーションを一のCPUから他のCPUに移行させる。または、移行処理については、メモリコントローラ509が一のCPUから他のアプリケーションを他のCPUに移行させる移行指示を他のCPUに通知する。そして、他のCPUが他のアプリケーションを一のCPUから他のCPUに移行させる。
 または、移行処理については、メモリコントローラ509が、一のCPUへ応答確認を通知し、通知後から所定時間以内に一のCPUから応答がない場合、一のCPUから他のアプリケーションを他のCPUに移行させる移行指示を他のCPUに通知する。そして、他のCPUが他のアプリケーションを一のCPUから他のCPUに移行させる。
 一のCPUから応答がないと、一のCPUがエラー状態で動作していない可能性がある。すなわち、一のCPUが移行処理を実行できない可能性があるため、メモリコントローラ509は他のCPUに移行処理を実行させる。一のCPUから応答がある場合、メモリコントローラ509は一のCPUと他のCPUのいずれか一方に移行処理を実行させればよい。以下の詳細な例では、一のCPUから応答がある場合、メモリコントローラ509は一のCPUに移行処理を実行させる。
 図9は、アクセス回数に関するアクセスログの一例を示す説明図である。図9では、アプリ#0のアクセス回数に関するアクセスログ900の一例を示す。アクセスログ900は、平均アクセス回数の項目901と、許容範囲の項目902と、アクセス回数の項目903と、優先度の項目904と、を有している。
 平均アクセス回数の項目901には、アプリ#0が正常動作した場合に所定時間あたりで共有メモリ510へアクセスする平均の回数が登録されている。ここで、所定時間とは、解析終了後から次のタイマ割り込みの発生までの時間である。平均アクセス回数は、具体的には、たとえば、アプリ#0の設計時にESL(Electronic System Level)検証ツールを用いて検証することで特定することができる。図9では、1000回が登録されている。
 許容範囲の項目902には、平均アクセス回数の項目901に登録されている平均アクセス回数に基づいて、アプリ#0から共有メモリ510へのアクセス回数が正常範囲内であると判断可能な範囲が登録されている。図9では、±10[%]が登録されている。すなわち、所定時間あたりの平均合計アクセス回数が1000回であるため、900回から1100回までが許容範囲である。
 アクセス回数の項目903は、所定時間内の現実行でのアプリ#0に関するアクセス回数が登録される。アクセス回数は、アプリ#0が割り当てられたCPU#0によってカウントされる。優先度の項目904は、アプリ#0の共有メモリ510へのアクセスの優先度が登録される。ここでは、優先度の項目904には、DEFAULTまたはLOWのうちのいずれか一方が登録される。LOWはDEFAULT時よりもアクセスの比率が低いことを示している。DEFAULTのアクセス比率とLOWのアクセス比率については、アプリケーションごとに決定されていてもよいし、同一値であってもよい。
 まず、メモリコントローラ509は、タイマ割り込みを検出すると、各CPUに割当済のアプリケーションの中から、未解析のアプリケーションを1つ選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。
 図10は、実施例1にかかるアクセスログ900の一例を示す説明図である。メモリコントローラ509が、アクセスログ解析部802により、アプリ#0に関するアクセスログ900を参照し、アプリ#0のアクセス回数が許容範囲内であるか否かを判断する。アクセスログ900のアクセス回数の項目903に登録されている値が1200回である。許容範囲が900~1100である。
 よって、アプリ#0のアクセス回数は許容範囲内でないと判断される。メモリコントローラ509が、リクエスト制御部801により、アプリ#0の割当先CPUを特定し、該割当先CPUに応答信号を送信して、指定時間以内に特定した割当先CPUから応答があるか否か判断する。ここでは、CPU#0がアプリ#0の割当先CPUであり、メモリコントローラ509がCPU#0に応答信号を送信する。
 応答信号を送信後から所定時間以内にCPU#0からメモリコントローラ509へ応答信号がある場合、CPU#0は動作可能な状態ではあるが、アプリ#0またはOS521がエラー状態である可能性がある。応答信号を送信後から所定時間以内にCPU#0からメモリコントローラ509へ応答信号がない場合、CPU#0は動作不能なエラー状態である可能性がある。ここでは、CPU#0からメモリコントローラ509へ応答信号がある場合とない場合とを分けて説明する。
<応答信号あり>
 まず、メモリコントローラ509が、応答信号を送信後から所定時間以内にCPU#0からの応答信号を受け付けた場合、最小負荷CPU特定部804により、マルチコアプロセッサのCPU#0を除くCPU#1とCPU#2とから最小負荷のCPUを特定する。具体的には、たとえば、メモリコントローラ509がCPUごとに該CPUに割り当てられているアプリケーションの実行時間の合計値を算出し、最も合計値が小さいCPUを最小負荷のCPUとする。
 CPU#1に割当済のアプリケーションの実行時間の合計値は200[μs]であり、CPU#2に割当済のアプリケーションの実行時間の合計値は1[ms]であるため、CPU#1が最小負荷のCPUとして特定される。ここでは、メモリコントローラ509が最小負荷のCPUを特定するが、CPU#0に最小負荷のCPUを特定させてもよい。
 そして、メモリコントローラ509が、リクエスト制御部801により、CPU#0へOS521に実行権を渡す割り込み信号を送信する。メモリコントローラ509が、割当済のアプリケーションの中でアプリ#0を除くすべてのアプリケーションをCPU#0からCPU#1にマイグレーションさせる移行指示をCPU#0に通知する。ここでは、アプリ#2が移行対象となる。
 図11は、アプリ#2が移行される例を示す説明図である。OS521が、移行指示を受け付けると、1次キャッシュ501に記憶されたアプリ#2の実行データを1次キャッシュ502にスヌープ回路504を用いて移行させる。そして、OS521が、アプリ#2のコンテキスト情報のポインタをCPU#1のレディーキュー532に積むことにより、マイグレーションが終了する。OS521が、移行終了をメモリコントローラ509に通知する。メモリコントローラ509が、移行終了を受け付けると、リクエスト制御部801により、CPU#0をソフトウェアリセットさせるリセット処理を制御する。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ900内のアクセス回数の項目903の値をクリアする。
 図12は、ソフトウェアリセットの一例を示す説明図である。ここで、ソフトウェアリセットとは、CPU上で動作するOSをリブートさせることを示している。メモリコントローラ509がCPU#0をソフトウェアリセットさせるリセット処理を制御するとは、具体的には、たとえば、メモリコントローラ509が、(1)CPU#0にリブートさせるリブート指示をOS521へ通知する。
 そして、OS521が、リブート指示を受け付けると、ブートシーケンスが記述されたブートローダを共有メモリ510のROM513から読み出して、共有メモリ510のRAM512または1次キャッシュ501へ展開する。つぎに、OS521が、(2)RAM512または1次キャッシュ501に展開したブートローダの読み出し先アドレスをCPU#0のPCに格納する。OS521が、CPU#0のリセットレジスタの値をセットする。これにより、OS521がリブートする。
<応答信号なし>
 つぎに、メモリコントローラ509が、応答信号を送信後から一定時間以内にCPU#0からの応答信号を受け付けなかった場合、マルチコアプロセッサのCPU#0を除くCPU#1とCPU#2とから最小負荷のCPUを特定する。最小負荷のCPUの特定処理については応答信号ありの場合で示した処理と同一であるため、ここでは、CPU#1が最小負荷のCPUであるとして、詳細な説明を省略する。
 そして、メモリコントローラ509が、CPU#1へOS522に実行権を渡す割り込み信号を送信する。メモリコントローラ509が、割当済のアプリケーションの中でアプリ#0を除くすべてのアプリケーションをCPU#0からCPU#1にマイグレーションさせる移行指示をCPU#1に通知する。ここでは、アプリ#2が移行対象となる。
 OS522が、移行指示を受け付けると、1次キャッシュ501に記憶されたアプリ#2の実行データを1次キャッシュ502にスヌープ回路504を用いて移行させる。そして、OS522が、アプリ#2のコンテキスト情報のポインタをCPU#1のレディーキュー532に積むことにより、マイグレーションが終了する。OS522が、移行終了をメモリコントローラ509に通知する。
 メモリコントローラ509が、OS522から移行終了を受け付けると、CPU#0をハードウェアリセットする。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ900内のアクセス回数の項目903の値をクリアする。
 図13は、ハードウェアリセットの一例を示す説明図である。ここで、メモリコントローラ509がハードウェアリセットするとは、たとえば、PMU511にCPU#0への電源を遮断させ、その後、再度電源電圧を供給させることである。PMU511からCPU#0への電源供給配線VDD0の電圧変化を用いて詳細に説明する。具体的には、たとえば、メモリコントローラ509が、(1)PMU511にCPU#0の識別情報を通知する。PMU511が、(2)該通知を受け付けると、(3)識別情報が示すCPU#0への電源供給を所定時間遮断する。図13での所定時間とは、CPU#0の内部状態をリセット可能な定義された時間である。
 CPU#0は、電源供給が所定時間遮断されることにより、(4)1次キャッシュ501やレジスタの設定がリセットされる。その後、PMU511が(5)再度電源電圧を供給し、(6)リセット完了をメモリコントローラ509に通知する。CPU#0に電源供給が再開されると、CPU#0が(7)OS521をブートする。
(アクセス回数に関するアクセスログの更新処理)
 図14は、アクセス回数に関するアクセスログの更新処理の更新処理手順例を示すフローチャートである。本更新処理手順は、OSごとに行われる。まず、OSが、共有メモリ510へのアクセスが発生したか否かを判断し(ステップS1401)、共有メモリ510へのアクセスが発生していないと判断した場合(ステップS1401:No)、ステップS1401へ戻る。OSが、共有メモリ510へのアクセスが発生したと判断した場合(ステップS1401:Yes)、アクセスを発生したアプリケーションに関するアクセスログ内のアクセス回数をカウントアップし(ステップS1402)、ステップS1401へ戻る。
(実施例1にかかるメモリコントローラ509による制御処理)
 図15および図16は、実施例1にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。まず、メモリコントローラ509が、タイマ割り込みが発生したか否かを判断する(ステップS1501)。メモリコントローラ509が、タイマ割り込みが発生していないと判断した場合(ステップS1501:No)、ステップS1501へ戻る。
 メモリコントローラ509が、タイマ割り込みが発生したと判断した場合(ステップS1501:Yes)、実行中のアプリケーションの中で、未解析のアプリケーションがあるか否かを判断する(ステップS1502)。メモリコントローラ509が、未解析のアプリケーションがあると判断した場合(ステップS1502:Yes)、未解析のアプリケーションから、任意のアプリケーションを選択する(対象アプリケーション)(ステップS1503)。
 つぎに、メモリコントローラ509が、アクセス回数が許容範囲内であるか否かを判断する(ステップS1504)。メモリコントローラ509が、アクセス回数が許容範囲内であると判断した場合(ステップS1504:Yes)、ステップS1517へ移行する。メモリコントローラ509が、アクセス回数が許容範囲内でないと判断した場合(ステップS1504:No)、対象アプリケーションの割当先CPU(障害CPU)に応答信号を送信する(ステップS1505)。メモリコントローラ509が、一定時間以内に障害CPUから応答有りか否かを判断する(ステップS1506)。メモリコントローラ509が、一定時間以内に障害CPUから応答あると判断した場合(ステップS1506:Yes)、マルチコアプロセッサのうちの障害CPUを除くCPUから、最小負荷のCPUを特定する(ステップS1507)。
 つぎに、メモリコントローラ509が、障害CPUへOSに実行権を渡す割り込み信号を通知し(ステップS1508)、障害CPUに割当済アプリケーションの中で対象アプリケーションを除くアプリケーションを特定したCPUへ移行させる移行指示を障害CPUへ通知する(ステップS1509)。そして、メモリコントローラ509が、移行終了したか否かを判断し(ステップS1510)、移行終了していないと判断した場合(ステップS1510:No)、ステップS1510へ戻る。メモリコントローラ509が、移行終了したと判断した場合(ステップS1510:Yes)、障害CPUをソフトウェアリセットさせ(ステップS1511)、ステップS1517へ移行する。
 ステップS1506において、メモリコントローラ509が、一定時間以内に障害CPUから応答なしと判断した場合(ステップS1506:No)、マルチコアプロセッサのうちの障害CPUを除くCPUから、最小負荷のCPUを特定する(ステップS1512)。メモリコントローラ509が、特定したCPUへOSに実行権を渡す割り込み信号を通知する(ステップS1513)。
 つぎに、メモリコントローラ509が、障害CPUに割当済アプリケーションの中で対象アプリケーションを除くアプリケーションを障害CPUから特定したCPUへ移行させる移行指示を特定したCPUへ通知する(ステップS1514)。そして、メモリコントローラ509が、移行が終了したか否かを判断し(ステップS1515)、移行が終了していないと判断した場合(ステップS1515:No)、ステップS1515へ戻る。一方、メモリコントローラ509が、移行が終了したと判断した場合(ステップS1515:Yes)、障害CPUをハードウェアリセットし(ステップS1516)、ステップS1517へ移行する。
 ステップS1504のYesの場合、ステップS1511、またはステップS1516のつぎに、対象アプリケーションに関するアクセスログから、対象アプリケーションのアクセス回数をクリアし(ステップS1517)、ステップS1502へ戻る。
(実施例2)
 実施例2では、メモリコントローラ509がマルチコアプロセッサのうちの一のCPUで実行中の対象アプリケーションからマルチコアプロセッサの各コアで共有する共有資源へのアクセスの傾向情報が許容範囲内であるか否かを判断する。そして、メモリコントローラ509が、アクセスの傾向情報が許容範囲内でないと判断した場合、対象アプリケーションから共有メモリ510へのアクセスの比率を判断前よりも下げる変更を行う。
 さらに、メモリコントローラ509が、該判断から所定時間経過後、判断から所定時間以内におけるアクセス回数が許容範囲内であるか否かを判断する。すなわち、アクセス回数が継続して許容範囲内でないかを判断する。メモリコントローラ509が、該判断から所定時間内におけるアクセス回数が許容範囲内でないと判断された場合、一のCPUに割当済の対象アプリケーションを除く他のアプリケーションを、一のCPUから他のCPUに移行させる。つぎに、詳細例を説明する。
 まず、メモリコントローラ509は、タイマ割り込みを検出すると、各CPUに割当済のアプリケーションの中から、任意の未解析のアプリケーションを選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。メモリコントローラ509が、アプリ#0に関するアクセスログ900を参照し、アプリ#0のアクセス回数が許容範囲内であるか否かを判断する。
 図10で示したアクセスログ900内のアクセス回数の項目903の値は1200回であり、許容範囲が900回~1100回であるため、アプリ#0から共有メモリ510へのアクセス回数が許容範囲内でないと判断される。メモリコントローラ509は、アプリ#0から共有メモリ510へのアクセスの比率を判断前よりも下げる。
 ここで、アプリ#0から共有メモリ510へのアクセスの比率を下げる例について2つ説明する。一の例では、アプリ#0からメモリコントローラ509へのアクセスについては変更せずに、メモリコントローラ509がアプリ#0から受け付けたアクセスを制御して、共有メモリ510へのアクセスの比率を下げる。
 また、アクセスの比率を下げる他の例としては、アプリ#0からメモリコントローラ509へのアクセスの比率をバス518のバス調停回路が下げることで、アプリ#0から共有メモリ510へのアクセスの比率を判断前よりも下げることができる。メモリコントローラ509がバス518のバス調停回路へアプリ#0の割当先CPUを通知する。
 該バス調停回路は、該割当先CPUからバス518へのアクセスをバッファリングするアウトスタンディングバッファからメモリコントローラ509へのアクセスの頻度を下げる。これにより、アプリ#0から共有メモリ510へのアクセスの比率を判断前よりも下げることができる。実施例2では、一の例を用いることとし、一の例について図17を用いて詳細に説明する。
 図17は、メモリコントローラ509がアクセスの比率を下げる例を示す説明図である。メモリコントローラ509は、リクエストキュー1700に登録されているアクセスのリクエスト順に各CPUからのアクセスを制御する。ここでは、たとえば、判断前の各CPUのアクセス比率が、下記であるとする。
 ・CPU#0の比率:CPU#1の比率:CPU#2の比率=5:2:1
 ここでは、各CPUのアクセス比率は、実行中のアプリケーションに基づいて決定されることとする。リクエストキュー1700の中の各ボックスがアクセスリクエストである。メモリコントローラ509は、リクエストキュー1700の右側からアクセスリクエストを受け付け、左側から順にアクセスリクエストを処理することとする。メモリコントローラ509が各CPUに対応するレジスタを有し、該レジスタに各CPUのアクセス比率を登録することとしてもよい。
 リクエストキュー1700内のボックスのうち、0が付されたボックスがCPU#0からのアクセスリクエストであり、1が付されたボックスがCPU#1からのアクセスリクエストであり、2が付されたボックスがCPU#2からのアクセスリクエストである。
 判断前のリクエストキュー1700(図上)内では、0が付されたボックスが5個並び、つぎに、1が付されたボックスが2個並び、2が付されたボックスが1個並び、再度、0が付されたボックスが5個並んでいる。すなわち、メモリコントローラ509は、CPU#0のアクセスリクエストを5回行い、つぎに、CPU#1のアクセスリクエストを2回行い、そして、CPU#2のアクセスリクエストを1回行う。
 判断後にメモリコントローラ509がアプリ#0を実行するCPU#0のアクセス比率を判断前よりも下げる。下げる量については限定しない。ここでは、たとえば、下げた後の各比率が、下記であるとする。
 ・CPU#0の比率:CPU#1の比率:CPU#2の比率=2:2:1
 下げた後のリクエストキュー1700(図下)内では、0が付されたボックスが2個並び、つぎに、1が付されたボックスが2個並び、2が付されたボックスが1個並び、再度、0が付されたボックスが2個並んでいる。すなわち、メモリコントローラ509は、CPU#0のアクセスリクエストを2回行い、つぎに、CPU#1のアクセスリクエストを2回行い、そして、CPU#2のアクセスリクエストを1回行う。本実施の形態では、DEFAULTのアクセス比率と、LOWのアクセス比率とが決定されていることとする。
 図18は、実施例2でのアクセスログ900を示す説明図(その1)である。さらに、メモリコントローラ509は、アプリ#0のアクセスログ900内の優先度の項目904の値をDEFAULTからLOWに変更する。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ900内のアクセス回数の項目903の値をクリアする。そして、割当済のアプリケーションから、アプリ#0を除くアプリケーションの中で、未解析のアプリケーションを選択し、解析する。
 つぎに、メモリコントローラ509は、つぎのタイマ割り込みを検出すると、各CPUに割当済のアプリケーションの中から、任意の未解析のアプリケーションを選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。
 図19は、実施例2でのアクセスログ900を示す説明図(その2)である。メモリコントローラ509が、アプリ#0に関するアクセスログ900を参照し、アプリ#0のアクセス回数が許容範囲内であるか否かを判断する。アクセスログ900のアクセス回数の項目903に登録されている値が2000回であり、許容範囲が900回~1100回であるため、アプリ#0のアクセス回数が許容範囲内でないと判断される。
 つぎに、メモリコントローラ509が、アプリ#0のアクセス回数が許容範囲内でないことが継続されているか否かを判断する。具体的には、たとえば、メモリコントローラ509が、アクセスログ900内の優先度の項目904の値がLOWである否かを確認する。LOWであれば、前回のタイマ割り込み時に、アクセス回数が許容範囲内でないと判断されていることを示している。
 たとえば、前回のタイマ割り込みと今回のタイマ割り込みとで連続して、アクセス回数が許容範囲内でない場合、アプリ#0またはアプリ#0の割当先CPUであるCPU#0がエラーである可能性が高い。たとえば、前回のタイマ割り込みでアクセス回数が許容範囲内でなく、今回のタイマ割り込みでアクセス回数が許容範囲内であれば、前回のタイマ割り込み時には、アプリ#0またはCPU#0の状態が不安定である。しかしながら、今回のタイマ割り込み時にはアプリ#0またはCPU#0の状態が正常であることを示している。
 ここでは、すでにアクセスログ900内の優先度の項目904の値がLOWであるため、アクセス回数が許容範囲内でない状態が継続していることを示している。つぎに、メモリコントローラ509が、アプリ#0の割当先CPUを特定し、該割当先CPUに信号を送信して、指定時間以内に特定した割当先CPUから応答があるか否か判断する。ここでは、CPU#0がアプリ#0の割当先CPUであり、メモリコントローラ509がCPU#0に応答信号を送信する。
 メモリコントローラ509が、応答信号を送信後から一定時間以内にCPU#0からの応答信号を受け付けた場合、マルチコアプロセッサのCPU#0を除くCPU#1とCPU#2とから最小負荷のCPUを特定する。具体的には、たとえば、メモリコントローラ509がCPUごとに該CPUに割り当てられているアプリケーションの実行時間の合計値を算出し、最も合計値が小さいCPUを最小負荷のCPUとする。
 CPU#1に割当済のアプリケーションの実行時間の合計値は200[μs]であり、CPU#2に割当済のアプリケーションの実行時間の合計値は1[ms]であるため、CPU#1が最小負荷のCPUとして特定される。ここでは、メモリコントローラ509が最小負荷のCPUを特定するが、CPU#0に最小負荷のCPUを特定させてもよい。
 そして、メモリコントローラ509が、CPU#0へOS521に実行権を渡す割り込み信号を送信し、割当済のアプリの中でアプリ#0を除くすべてのアプリをCPU#0からCPU#1にマイグレーションさせる移行指示をCPU#0に通知する。ここでは、アプリ#2が移行対象となる。
 OS521が、移行指示を受け付けると、1次キャッシュ501に記憶されたアプリ#2の実行データを1次キャッシュ502にスヌープ回路504を用いて移行させる。そして、OS521が、アプリ#2のコンテキスト情報のポインタをCPU#1のレディーキュー532に積むことにより、マイグレーションが終了する。OS521が、移行終了をメモリコントローラ509に通知する。
 メモリコントローラ509が移行終了を受け付けると、CPU#0をソフトウェアリセットする。ソフトウェアリセットについては、実施例1で示した例と同一であるため詳細な説明を省略する。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ900内のアクセス回数の項目903の値をクリアし、優先度の項目904の値をLOWからDEFAULTに変更する。
 また、メモリコントローラ509が、応答信号を送信後から一定時間以内にCPU#0からの応答信号を受け付けなかった場合(応答信号なし)については実施例1で説明した処理と同一であるため、実施例2における応答信号なしの場合の詳細な説明を省略する。
(実施例2にかかるメモリコントローラ509による制御処理)
 図20および図21は、実施例2にかかるメモリコントローラ509による制御処理の制御処理手順を示すフローチャートである。ステップS2001~ステップS2004はステップS1501~ステップS1504と同一処理であり、ステップS2010~ステップS2021はステップS1505~ステップS1516と同一処理であるため、ここでの詳細な説明は省略する。
 ステップS2004のNoの場合のつぎに、メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内であったか否かを判断する(ステップS2005)。メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内であったと判断した場合(ステップS2005:Yes)、対象アプリケーションのアクセスの優先度をLOWに変更する(ステップS2006)。メモリコントローラ509がステップS2006のつぎにステップS2009へ移行する。メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内でなかったと判断した場合(ステップS2005:No)、ステップS2010へ移行する。
 ステップS2004のYesの場合のつぎに、メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内であったか否かを判断する(ステップS2007)。メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内でなかったと判断した場合(ステップS2007:No)、対象アプリケーションのアクセスの優先度をDEFAULTに変更する(ステップS2008)。そして、メモリコントローラ509が、対象アプリケーションに関するアクセスログ内のアクセス回数をクリアし(ステップS2009)、ステップS2002へ戻る。
 メモリコントローラ509が、前回のタイマ割り込み時に、対象アプリケーションのアクセス回数が許容範囲内であったと判断した場合(ステップS2007:Yes)、ステップS2009へ移行する。
(実施例3)
 実施例3では、実施例1で説明した詳細についてアクセス回数に代わってメモリ番地を用いて説明する。
 図22は、メモリ番地に関するアクセスログの一例を示す説明図である。アプリ#0に関するアクセスログ2200では、スタートアドレスの項目2201と、エンドアドレスの項目2202と、アクセス割合の項目2203と、を有している。さらに、アプリ#0に関するアクセスログ2200では、許容範囲の項目2204と、平均アクセス回数の項目2205と、アクセス回数の項目2206と、優先度の項目2207と、を有している。
 スタートアドレスの項目2201と、エンドアドレスの項目2202とには、メモリ番地が登録されている。許容範囲の項目2204には、許容範囲が登録されている。アクセス割合の項目2203には、スタートアドレスの項目2201に登録されているメモリ番地からエンドアドレスの項目2202に登録されているメモリ番地までの領域に、アプリケーションの通常動作時にアクセスされる割合が登録されている。平均アクセス回数の項目2205には、アプリケーションの通常アクセス動作時に共有メモリ510へアクセスされる平均回数が登録されている。平均アクセス回数は、1000回である。
 たとえば、図22では、平均アクセス回数のうちの30[%]が0x00000000~0x000FFFFFにアクセスされることを示している。すなわち、1000回×30[%]で300回は0x00000000~0x000FFFFFにアクセスされることを示している。許容範囲が±10[%]であるため、アクセス回数で許容範囲を表すと、270回~330回までであり、アクセス割合で許容範囲を表すと、27[%]~33[%]までである。
 アクセス回数の項目2206には、一のタイマ割り込みから次のタイマ割り込みまでの間に、各アドレス範囲にメモリアクセスが何回発生したかが登録される。優先度の項目2207には、アプリ#0の共有メモリ510へのアクセスの優先度が登録される。ここでは、優先度の項目2207には、DEFAULTまたはLOWのうちのいずれか一方が登録される。LOWはDEFAULT時よりもアクセスの比率が低いことを示している。
 まず、メモリコントローラ509は、タイマ割り込みを検出すると、各CPUに割当済のアプリケーションの中から、任意の未解析のアプリケーションを選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。
 図23は、実施例3でのアクセスログ2200を示す説明図である。アクセスログ2200では、アクセス回数の項目2206が更新されている。0x00000000~0x000FFFFFには、100回アクセスされている。0x00000000~0x000FFFFFへのアクセスの割合は、1000回/100回で、10[%]である。
 0x00100000~0x001FFFFFには、400回アクセスされている。0x00100000~0x001FFFFFへのアクセスの割合は、1000回/400回で、40[%]アクセスされている。0xFFF00000~0xFFFFFFFFには、500回アクセスされている。0xFFF00000~0xFFFFFFFFへのアクセスの割合は、50[%]である。
 そして、メモリコントローラ509が、アプリ#0に関するアクセスログ2200を参照し、各メモリ番地へのアクセスの割合が許容範囲内であるか否かを判断する。たとえば、0xFFF00000~0xFFFFFFFFへのアクセスの割合は0[%]であり、該タイミング割り込みでのアクセスの割合は50[%]であるため、メモリコントローラ509が所定範囲内でないと判断する。
 よって、アプリ#0のアクセス回数は許容範囲内でないと判断される。メモリコントローラ509が、アプリ#0の割当先CPUを特定し、該割当先CPUに信号を送信して、指定時間以内に特定した割当先CPUから応答があるか否か判断する。ここでは、CPU#0がアプリ#0の割当先CPUであり、メモリコントローラ509がCPU#0に応答信号を送信する。
 メモリコントローラ509が、応答信号を送信後から一定時間以内にCPU#0からの応答信号を受け付けた場合、メモリコントローラ509が、マルチコアプロセッサのCPU#0を除くCPU#1とCPU#2とから最小負荷のCPUを特定する。ここでは、メモリコントローラ509が最小負荷のCPUを特定するが、CPU#0に最小負荷のCPUを特定させてもよい。
 そして、メモリコントローラ509が、CPU#0へOS521に実行権を渡す割り込み信号を送信し、割当済のアプリの中でアプリ#0を除くすべてのアプリをCPU#0からCPU#1にマイグレーションさせる移行指示をCPU#0に通知する。ここでは、アプリ#2が移行対象となる。
 OS521が、移行指示を受け付けると、1次キャッシュ501に記憶されたアプリ#2の実行データを1次キャッシュ502にスヌープ回路504を用いて移行させる。そして、OS521が、アプリ#2のコンテキスト情報のポインタをCPU#1のレディーキュー532に積むことにより、マイグレーションが終了する。OS521が、移行終了をメモリコントローラ509に通知する。メモリコントローラ509が移行終了を受け付けると、CPU#0をソフトウェアリセットする。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ2200内のアクセス回数の項目2206の値をクリアする。
 また、CPU#0からメモリコントローラ509へ一定時間以内に応答指示がある場合については実施例1で詳細に説明しているため、省略する。また、実施例3にかかる詳細な制御処理手順は、実施例1にかかる詳細な制御処理手順とアクセスの傾向情報が異なるだけであるため、ここでの説明は省略する。
(実施例3にかかるメモリ番地に関するアクセスログの更新処理)
 図24は、メモリ番地に関するアクセスログの更新処理の更新処理手順例を示すフローチャートである。本更新処理手順は、OSごとに行われる。まず、OSが、共有メモリ510へのアクセスが発生したか否かを判断し(ステップS2401)、共有メモリ510へのアクセスが発生していないと判断した場合(ステップS2401:No)、ステップS2401へ戻る。
 OSが、共有メモリ510へのアクセスが発生したと判断した場合(ステップS2401:Yes)、アクセスするメモリ番地を特定する(ステップS2402)。書き込み命令・読み出し命令には、アクセスするメモリ番地が含まれている。そして、OSが、アクセスを発生したアプリケーションに関するアクセスログ内の対応するメモリ番地のアクセス回数をカウントアップし(ステップS2403)、ステップS2401へ戻る。
(実施例4)
 実施例4では、実施例2で説明した詳細について、アクセス回数に代わってメモリ番地で説明する。まず、メモリコントローラ509は、タイマ割り込みを検出すると、各CPUに割当済のアプリケーションの中から、任意の未解析のアプリケーションを選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。
 メモリコントローラ509が、アプリ#0に関するアクセスログ2200を参照し、各メモリ番地へのアクセスの割合が許容範囲内であるか否かを判断する。0xFFF00000~0xFFFFFFFFへのアクセスの割合は0[%]であり、該タイミング割り込みでのアクセスの割合は150[%]であるため、メモリコントローラ509が所定範囲内でないと判断する。メモリコントローラ509は、アプリ#0から共有メモリ510へのアクセスの比率を判断前よりも下げる。アクセスの比率の下げ方については、実施例2で説明した例と同一例を用いることとする。
 図25は、実施例4でのアクセスログを示す説明図(その1)である。さらに、メモリコントローラ509は、アプリ#0のアクセスログ2200内の優先度の項目2207の値をDEFAULTからLOWに変更する。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ内のアクセス回数の項目2206の値をクリアする。そして、割当済のアプリケーションから、アプリ#0を除くアプリケーションの中で、未解析のアプリケーションを選択し、解析する。
 つぎに、メモリコントローラ509は、つぎのタイマ割り込みを検出すると、各CPUに割当済のアプリケーションのうちの未解析のアプリケーションから任意のアプリケーションを選択する。ここでは、CPU#0に割り当てられているアプリ#0が選択されることとする。
 図26は、実施例4でのアクセスログを示す説明図(その2)である。メモリコントローラ509が、アプリ#0に関するアクセスログ2200を参照し、各アドレスの番地にアクセスされるアクセスの割合が許容範囲内か否かを判断する。0xFFF00000~0xFFFFFFFFへのアクセス回数が2000回であり、アクセスの割合が200[%]であるため、アクセスの割合が、許容範囲内でないと判断される。
 つぎに、メモリコントローラ509が、アプリ#0のアクセス回数が許容範囲内でないことが継続されているか否かを判断する。具体的には、たとえば、メモリコントローラ509が、アクセスログ2200内の優先度の項目2207の値がLOWであるか否かを確認する。LOWであれば、前回のタイマ割り込み時に、アクセス回数が許容範囲内でないと判断されていることを示している。
 たとえば、前回のタイマ割り込みと今回のタイマ割り込みとで連続して、アクセス回数が許容範囲内でない場合、アプリ#0またはアプリ#0の割当先CPUであるCPU#0がエラーである可能性が高い。たとえば、前回のタイマ割り込みでアクセス回数が許容範囲内でなく、今回のタイマ割り込みでアクセス回数が許容範囲内であれば、前回のタイマ割り込み時には、アプリ#0またはCPU#0の状態が不安定である。しかしながら、今回のタイマ割り込み時にはアプリ#0またはCPU#0の状態が正常であることを示している。
 ここでは、すでにアクセスログ2200内の優先度の項目2207の値がLOWであるため、アクセス回数が許容範囲内でない状態が継続していることを示している。つぎに、メモリコントローラ509が、アプリ#0の割当先CPUを特定し、該割当先CPUに信号を送信して、指定時間以内に特定した割当先CPUから応答があるか否か判断する。ここでは、CPU#0がアプリ#0の割当先CPUであり、メモリコントローラ509がCPU#0に応答信号を送信する。
 メモリコントローラ509が、応答信号を送信後から一定時間以内にCPU#0からの応答信号を受け付けた場合、メモリコントローラ509が、マルチコアプロセッサのCPU#0を除くCPU#1とCPU#2とから最小負荷のCPUを特定する。具体的には、たとえば、メモリコントローラ509がCPUごとに該CPUに割り当てられているアプリケーションの実行時間の合計値を算出し、最も合計値が小さいCPUを最小負荷のCPUとする。CPU#1に割当済のアプリケーションの実行時間の合計値は200[μs]であり、CPU#2に割当済のアプリケーションの実行時間の合計値は1[ms]であるため、CPU#1が最小負荷のCPUとして特定される。ここでは、メモリコントローラ509が最小負荷のCPUを特定するが、CPU#0に最小負荷のCPUを特定させてもよい。
 そして、メモリコントローラ509が、CPU#0へOS521に実行権を渡す割り込み信号を送信し、割当済のアプリの中でアプリ#0を除くすべてのアプリをCPU#0からCPU#1にマイグレーションさせる移行指示をCPU#0に通知する。ここでは、アプリ#2が移行対象となる。
 OS521が、移行指示を受け付けると、1次キャッシュ501に記憶されたアプリ#2の実行データを1次キャッシュ502にスヌープ回路504を用いて移行させる。そして、OS521が、アプリ#2のコンテキスト情報のポインタをCPU#1のレディーキュー532に積むことにより、アプリ#2のマイグレーションが終了する。OS521が、移行終了をメモリコントローラ509に通知する。
 メモリコントローラ509が移行終了を受け付けると、CPU#0をソフトウェアリセットする。そして、メモリコントローラ509が、アプリ#0に関するアクセスログ2200内のアクセス回数の項目2206の値をクリアし、優先度の項目2207の値をLOWからDEFAULTに変更する。
 また、実施例4にかかる詳細な制御処理手順は、実施例2にかかる詳細な制御処理手順とアクセスの傾向情報が異なるだけであるため、ここでの説明は省略する。
 以上実施例1,実施例3で説明したように、プロセッサ処理方法、および制御装置によれば、一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内でない場合、一のCPUに割当済の他のアプリケーションを他のCPUに移行させる。すなわち、一のCPUで実行中のアプリのメモリアクセスの傾向が、通常のアプリケーションの実行時と異なる場合、対象アプリケーションまたは一のCPUにエラーの可能性がある。そこで、一のCPUに割当済の他のアプリケーションを他のCPUに避難させることにより、該エラーの影響を他のアプリケーションに波及させることを防止することができる。
 また、一のCPUに割当済の他のアプリケーションを一のCPUから他のCPUに移行させる移行処理を一のCPUに移行指示を通知することで、一のCPUに移行処理を実行させる。これにより、割当済の他のアプリケーションを他のCPUに避難させることができ、エラーの影響を他のアプリケーションに波及させることを防止することができる。
 また、一のCPUに割当済の他のアプリケーションを一のCPUから他のCPUに移行させる移行処理を他のCPUに移行指示を通知することで、他のCPUに移行処理を実行させる。これにより、割当済の他のアプリケーションを他のCPUに避難させることができ、エラーの影響を他のアプリケーションに波及させることを防止することができる。
 また、一のCPUに応答確認を行い、応答がない場合、一のCPUに割当済の他のアプリケーションを一のCPUから他のCPUに移行させる移行処理を他のCPUに移行指示を通知することで、他のCPUに移行処理を実行させる。これにより、一のCPUがエラー状態で他のアプリケーションが実行されていないため、他のアプリケーションを実行させるために他のCPUに移行させることで、他のアプリケーションを通常通り実行させることができる。
 また、他のアプリケーションを他のCPUに移行後、一のCPUをソフトウェアリセットさせることにより、共有メモリ内の一のCPUが使用する領域がリセットされ、一のCPUをエラー状態から回復させることができる。
 また、他のアプリケーションを他のCPUに移行後、一のCPUをハードウェアリセットさせることにより、共有メモリ内の一のCPUが使用する領域と一のCPU内のレジスタの値がリセットされ、一のCPUをエラー状態から回復させることができる。
 以上、実施例2,4で説明したように、一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内であるか否かを判断する。共有メモリへのアクセスの傾向情報が許容範囲内でないとは、実行中の対象アプリのメモリアクセスの傾向が通常時の傾向と異なる場合である。すなわち、対象アプリまたは対象アプリの割当先コアにエラーの疑いがある。そして、対象アプリケーションから共有メモリへのアクセスの優先度を判断前よりも下げることで、他のCPUで実行中のアプリケーションからのメモリアクセスに影響を与えるのを防止することができる。
 また、判断後から所定時間経過後に、一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内であるか否かを判断する。すなわち、複数回に渡って、一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内であるか否かを判断する。一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内でないことが継続している場合、エラー状態である可能性が高くなるので、一のCPUに割当済の他のアプリケーションを他のCPUに移行させる。これにより、一のアプリケーションに割当済の他のアプリケーションにエラーの影響が波及するのを防止することができる。
 また、共有メモリへのアクセスの傾向情報が許容範囲内でないと過去に判断され、共有メモリへのアクセスの傾向情報が許容範囲内であると今回判断された場合、該アクセスの優先度を上げる。一のCPUで実行中の対象アプリケーションのメモリアクセスの傾向情報が許容範囲内でないことが継続していない場合、エラー状態ではない可能性がある。これにより、エラー状態であるか否かの判断の精度を向上させることができる。
 また、他のアプリケーションを他のCPUに移行後、一のCPUをリセットさせることにより、一のCPUをエラー状態から回復させることができる。
 また、他のアプリケーションを他のCPUに移行後、一のCPUをソフトウェアリセットさせることにより、共有メモリ内の一のCPUが使用する領域がリセットされ、一のCPUをエラー状態から回復させることができる。
 また、他のアプリケーションを他のCPUに移行後、一のCPUをハードウェアリセットさせることにより、共有メモリ内の一のCPUが使用する領域と一のCPU内のレジスタの値がリセットされ、一のCPUをエラー状態から回復させることができる。
 また、対象アプリケーションから共有メモリへのアクセスの傾向情報がアクセス回数に関する情報である。たとえば、通常動作時よりもアクセス回数が多ければ、異常状態であるため、他のCPUから共有メモリへのアクセスの妨げになる。また、たとえば、アクセス回数が通常動作時よりも少なければ、すなわち、一定時間共有メモリへアクセスがなければ、対象アプリケーションがハングアップ状態である可能性がある。これにより、他のCPUから共有メモリへのアクセスの妨げとなる状態やハングアップ状態を容易に検出することができる、マルチコアプロセッサシステム全体の演算性能の劣化を防止することができ、信頼性を向上させることができる。
 また、対象アプリケーションから共有メモリへのアクセスの傾向情報がアクセスするメモリ番地に関する情報である。たとえば、通常動作時のメモリ番地と異なるメモリ番地にアクセスしている場合、対象アプリケーションがエラー命令を実行している可能性がある。これにより、エラー状態を容易に検出することができ、マルチコアプロセッサシステム全体の演算性能の劣化を防止することができ、信頼性を向上させることができる。
 本プロセッサ処理方法は、リクエスト制御部801~I/O制御部806を有するメモリコントローラ509によって実現することができる。
 500 マルチコアプロセッサシステム
 801 リクエスト制御部
 802 アクセスログ解析部
 803 優先度変更部
 804 最小負荷CPU特定部
 805 メモリ制御部

Claims (11)

  1.  第1のCPU(Central Processing Unit)が実行中の第1アプリケーションが正常に動作しているか否かを前記第1アプリケーションの共有資源へのアクセスログに基づいて判断し、
     前記第1アプリケーションが正常動作していないと判断されたときに、前記第1のCPUによって実行される前記第1アプリケーション以外の第2アプリケーションを第2のCPUに実行させること
     を特徴とするプロセッサ処理方法。
  2.  前記第1アプリケーションが正常に動作していないと判断されたときに、前記第1アプリケーションの前記共有資源へのアクセスの優先度を下げること
     を特徴とする請求項1に記載のプロセッサ処理方法。
  3.  前記第1アプリケーションが正常に動作していないと複数回判断されたときに、前記第2アプリケーションを前記第2のCPUに実行させること
     を特徴とする請求項1または請求項2に記載のプロセッサ処理方法。
  4.  前記第1アプリケーションが正常に動作していると判断されたときに、前記第1アプリケーションが正常に動作していないと過去に判断されているときには、前記第1アプリケーションの前記共有資源へのアクセスの優先度を上げること
     を特徴とする請求項1、請求項2または請求項3に記載のプロセッサ処理方法。
  5.  前記第1アプリケーションが正常に動作していないと判断されたときに、前記第1のCPUに信号が供給されること
     を特徴とする請求項1乃至請求項4の何れか一に記載のプロセッサ処理方法。
  6.  前記第1のCPUが前記信号に対する応答を送信したときには、前記第1のCPUが前記第2アプリケーションを前記第2のCPUに受け渡すこと
     を特徴とする請求項5に記載のプロセッサ処理方法。
  7.  前記第1のCPUが前記信号に対する応答を送信しないときには、前記第2のCPUが前記第2アプリケーションを前記第2のCPUに退避させること
     を特徴とする請求項5に記載のプロセッサ処理方法。
  8.  第1のCPUが実行中の第1アプリケーションが正常に動作しているか否かを前記第1アプリケーションの共有資源へのアクセスログに基づいて判断し、
     前記第1アプリケーションが正常に動作していないと判断されたときに、前記第1アプリケーションの前記共有資源へのアクセスの優先度を下げること
     を特徴とするプロセッサ処理方法。
  9.  複数のCPUと、
     前記複数のCPUで共有される共有資源へのアクセスを制御する制御装置と、を備え、
     前記制御装置が、
     第1のCPUが実行中の第1アプリケーションが正常に動作しているか否かを前記第1アプリケーションの前記共有資源へのアクセスログに基づいて判断し、
     前記第1アプリケーションが正常動作していないと判断されたときに、前記第1のCPUによって実行される前記第1アプリケーション以外の第2アプリケーションを第2のCPUに実行させること
     を特徴とするプロセッサシステム。
  10.  前記第1アプリケーションが正常に動作していないと判定されたときに、前記第1アプリケーションの前記共有資源へアクセスの優先度が下げられること
     を特徴とする請求項9に記載のプロセッサシステム。
  11.  前記第1アプリケーションが正常に動作していると判定されたときに、前記第1アプリケーションが正常に動作していないと過去に判定されているときには、前記第1アプリケーションの前記共有資源へのアクセスの優先度が上げられること
     を特徴とする請求項9または10に記載のプロセッサシステム。
PCT/JP2011/051353 2011-01-25 2011-01-25 プロセッサ処理方法、およびプロセッサシステム WO2012101759A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2012554531A JP5704176B2 (ja) 2011-01-25 2011-01-25 プロセッサ処理方法、およびプロセッサシステム
PCT/JP2011/051353 WO2012101759A1 (ja) 2011-01-25 2011-01-25 プロセッサ処理方法、およびプロセッサシステム
US13/949,922 US20130318310A1 (en) 2011-01-25 2013-07-24 Processor processing method and processor system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/051353 WO2012101759A1 (ja) 2011-01-25 2011-01-25 プロセッサ処理方法、およびプロセッサシステム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/949,922 Continuation US20130318310A1 (en) 2011-01-25 2013-07-24 Processor processing method and processor system

Publications (1)

Publication Number Publication Date
WO2012101759A1 true WO2012101759A1 (ja) 2012-08-02

Family

ID=46580366

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/051353 WO2012101759A1 (ja) 2011-01-25 2011-01-25 プロセッサ処理方法、およびプロセッサシステム

Country Status (3)

Country Link
US (1) US20130318310A1 (ja)
JP (1) JP5704176B2 (ja)
WO (1) WO2012101759A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8954782B2 (en) * 2011-08-24 2015-02-10 Dell Products, Lp System and method for an integrated open network switch
US10642782B2 (en) * 2016-12-08 2020-05-05 Electronics And Telecommunications Research Institute Multi-core processor and operation method thereof
KR102285084B1 (ko) * 2019-12-24 2021-08-03 주식회사 텔레칩스 이종의 멀티 cpu를 운용하는 시스템-온-칩 및 그 동작 방법

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000010800A (ja) * 1998-06-19 2000-01-14 Toshiba Corp 計算機システムに於けるスレッド制御装置、及び同システムに於けるスレッド制御方法
JP2002344450A (ja) * 2001-05-15 2002-11-29 Hitachi Ltd 高可用性処理方法及びその実施システム並びにその処理プログラム
JP2005071119A (ja) * 2003-08-26 2005-03-17 Hitachi Ltd 系切替方法、レプリカ作成方法、及びディスク装置
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム
JP2009237758A (ja) * 2008-03-26 2009-10-15 Nec Corp サーバシステム、サーバ管理方法、およびそのプログラム
JP2010039685A (ja) * 2008-08-04 2010-02-18 Hitachi Ltd 複合型計算機及び複合型計算機の制御方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06124248A (ja) * 1992-10-12 1994-05-06 Fujitsu Ltd バス制御回路
US5845061A (en) * 1994-10-31 1998-12-01 Hitachi, Ltd. Redundant client server system
JPH09282252A (ja) * 1996-04-15 1997-10-31 Hitachi Ltd ネットワーク管理方式
US20030037280A1 (en) * 2001-08-20 2003-02-20 Berg Jerry D. Computer memory error management system and method
JP2004078936A (ja) * 2002-07-31 2004-03-11 Matsushita Electric Ind Co Ltd 情報処理端末及び情報処理方法
JP2004133496A (ja) * 2002-10-08 2004-04-30 Hitachi Ltd コンピュータシステム
JP2004171072A (ja) * 2002-11-18 2004-06-17 Nec Engineering Ltd マルチプロセッサ構成の障害検出方式
JP4114879B2 (ja) * 2005-01-21 2008-07-09 インターナショナル・ビジネス・マシーンズ・コーポレーション トレース情報収集システム、トレース情報収集方法、及びトレース情報収集プログラム
CN102016873A (zh) * 2008-06-24 2011-04-13 松下电器产业株式会社 访问控制装置、访问控制程序及访问控制方法

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000010800A (ja) * 1998-06-19 2000-01-14 Toshiba Corp 計算機システムに於けるスレッド制御装置、及び同システムに於けるスレッド制御方法
JP2002344450A (ja) * 2001-05-15 2002-11-29 Hitachi Ltd 高可用性処理方法及びその実施システム並びにその処理プログラム
JP2005071119A (ja) * 2003-08-26 2005-03-17 Hitachi Ltd 系切替方法、レプリカ作成方法、及びディスク装置
JP2007207219A (ja) * 2006-01-06 2007-08-16 Hitachi Ltd 計算機システムの管理方法、管理サーバ、計算機システム及びプログラム
JP2009237758A (ja) * 2008-03-26 2009-10-15 Nec Corp サーバシステム、サーバ管理方法、およびそのプログラム
JP2010039685A (ja) * 2008-08-04 2010-02-18 Hitachi Ltd 複合型計算機及び複合型計算機の制御方法

Also Published As

Publication number Publication date
JPWO2012101759A1 (ja) 2014-06-30
JP5704176B2 (ja) 2015-04-22
US20130318310A1 (en) 2013-11-28

Similar Documents

Publication Publication Date Title
US8429667B2 (en) Storage system and method for controlling the same
US7428629B2 (en) Memory request / grant daemons in virtual nodes for moving subdivided local memory space from VN to VN in nodes of a massively parallel computer system
US20140019738A1 (en) Multicore processor system and branch predicting method
US20150254113A1 (en) Lock Spin Wait Operation for Multi-Threaded Applications in a Multi-Core Computing Environment
US9311142B2 (en) Controlling memory access conflict of threads on multi-core processor with set of highest priority processor cores based on a threshold value of issued-instruction efficiency
US20140026143A1 (en) Exclusive access control method and computer product
JP5499987B2 (ja) 共有キャッシュメモリ装置
JP6028415B2 (ja) 仮想サーバ環境のデータ移行制御装置、方法、システム
US20150194198A1 (en) Multi-core processor system, memory controller control method, and computer product
JP5704176B2 (ja) プロセッサ処理方法、およびプロセッサシステム
US20130298132A1 (en) Multi-core processor system and scheduling method
JP4253796B2 (ja) コンピュータ及び制御方法
US20140053162A1 (en) Thread processing method and thread processing system
JP6380261B2 (ja) 電子機器および給電制御プログラム
JP5376042B2 (ja) マルチコアプロセッサシステム、スレッド切り替え制御方法、およびスレッド切り替え制御プログラム
JP2008165318A (ja) 計算機システム
JP4878050B2 (ja) コンピュータ及び制御方法
JP2008250419A (ja) 競合調停装置、マスタスレーブシステム及び競合調停方法
JP5582241B2 (ja) マルチコアプロセッサシステム、マルチコアプロセッサシステムの制御方法、およびマルチコアプロセッサシステムの制御プログラム
JP4780327B2 (ja) パーティション・コンテキスト制御装置及び方法、並びにコンピュータ
JP6073955B2 (ja) 複数の論理コアの実装を可能にするマイクロプロセッサのスタンバイの管理を最適化するための方法およびそのような方法を実行するコンピュータプログラム
CN114691296A (zh) 中断处理方法、装置、介质及设备
JP5146272B2 (ja) 情報処理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11857231

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012554531

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11857231

Country of ref document: EP

Kind code of ref document: A1