JPWO2011114477A1 - 階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム - Google Patents
階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム Download PDFInfo
- Publication number
- JPWO2011114477A1 JPWO2011114477A1 JP2012505384A JP2012505384A JPWO2011114477A1 JP WO2011114477 A1 JPWO2011114477 A1 JP WO2011114477A1 JP 2012505384 A JP2012505384 A JP 2012505384A JP 2012505384 A JP2012505384 A JP 2012505384A JP WO2011114477 A1 JPWO2011114477 A1 JP WO2011114477A1
- Authority
- JP
- Japan
- Prior art keywords
- cpu
- cluster
- layer
- group
- core processor
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
- G06F15/163—Interprocessor communication
- G06F15/173—Interprocessor communication using an interconnection network, e.g. matrix, shuffle, pyramid, star, snowflake
- G06F15/17356—Indirect interconnection networks
- G06F15/17368—Indirect interconnection networks non hierarchical topologies
- G06F15/17393—Indirect interconnection networks non hierarchical topologies having multistage networks, e.g. broadcasting scattering, gathering, hot spot contention, combining/decombining
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Mathematical Physics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
Abstract
マルチコアプロセッサシステム(100)では、OSI参照モデルのセッション層のプロトコルに関する処理をz=0のCPU群が実行し、プレゼンテーション層のプロトコルに関する処理をz=1のCPU群が実行し、アプリケーション層のプロトコルに関する処理をz=2のCPU群が実行する。アプリケーションソフトウェアに関する処理をメインCPU(101)が実行する。z=0のCPU群はローカルメモリ(201)を介してz=1のCPU群に接続され、z=1のCPU群はローカルメモリ(202)を介してz=2のCPU群に接続され、z=2のCPU群はローカルメモリ(203)を介してメインCPU(101)に接続されている。パケットはOSI参照モデルの階層順に受け渡されるため、z=0のCPU群とz=2のCPU群は直接接続されずにz=1のCPU群を介してのみ接続されている。
Description
本発明は、通信機能に関する処理を実行する階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラムに関する。
従来、マルチコアプロセッサシステムにおいてCPU群を1つのクラスタとして、アプリケーションソフトウェア(以下、「アプリケーション」と称する。)ごとに各クラスタでアプリケーションを実行する技術(従来技術1)が知られている(たとえば、下記特許文献1,2参照。)。マルチコアプロセッサシステムにおいてすべてのCPUを等価に接続するとシステムが大規模になるため、クラスタを階層構造とし、結線を最適化する技術(従来技術2)が知られている(たとえば、下記特許文献3参照。)。
しかしながら、従来技術1では、1アプリケーションソフトウェアに関する処理に対して1クラスタを割り当てるため、同時実行するアプリケーションが増えると、クラスタも増やさなければならず、システムが大規模になる問題点があった。また、従来技術2では、クラスタが階層構造であっても同一階層のすべてのクラスタ間を相互に接続させる必要があり、システムが大規模になる問題点があった。
本発明は、上述した従来技術による問題点を解消するため、CPU間の接続数を減らすことで、システムの大規模化を抑制することができる階層型マルチコアプロセッサを提供することを目的とする。
本発明の一観点によれば、通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続される階層型マルチコアプロセッサが提供される。
本階層型マルチコアプロセッサによれば、CPU間の接続数を減らすことで、システムの大規模化を抑制することができるという効果を奏する。
以下に添付図面を参照して、本発明にかかる階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラムの好適な実施の形態を詳細に説明する。
(マルチコアプロセッサシステムのハードウェア構成)
図1は、マルチコアプロセッサシステムのハードウェア構成の一例を示すブロック図である。図1において、マルチコアプロセッサシステム100は、メインCPU101(Central Processing Unit)と、階層型マルチコアプロセッサ102と、通信CPU103と、RF104と、メモリ105と、メモリ106と、アンテナ110と、を有する。メインCPU101とメモリ105は、バス107により接続されている。そして、通信CPU103とメモリ106はバス108により接続されている。バス107とバス108はブリッジ109を介して接続されている。
図1は、マルチコアプロセッサシステムのハードウェア構成の一例を示すブロック図である。図1において、マルチコアプロセッサシステム100は、メインCPU101(Central Processing Unit)と、階層型マルチコアプロセッサ102と、通信CPU103と、RF104と、メモリ105と、メモリ106と、アンテナ110と、を有する。メインCPU101とメモリ105は、バス107により接続されている。そして、通信CPU103とメモリ106はバス108により接続されている。バス107とバス108はブリッジ109を介して接続されている。
ここで、メインCPU101は、アプリケーションソフトウェアに関する処理の全体の制御を司るプロセッサであり、一次キャッシュが内蔵されている。通信CPU103は、通信に関する処理の全体の制御を司るプロセッサである。なお、通信用の通信CPU103とアプリケーション用のメインCPU101とを別個に持つ構成は周知である。
RF104は、高周波処理部であり、アンテナ110を介してインターネットなどのネットワークからデータを受信したり、該ネットワークへデータを送信したりする。ここでは、RF104は、A(Analog)/D(Digital)コンバータやD(Digital)/A(Analog)コンバータなどを備えていることとし、ネットワークからのデータをディジタル信号に変換したり、通信CPU103からのデータをアナログ信号に変換したりする。
階層型マルチコアプロセッサ102は、通信CPU103からのデータをメインCPU101で使用可能な状態に変換、またはメインCPU101からのデータを通信CPU103で使用可能な状態に変換する。階層型マルチコアプロセッサ102は、CPU群(図中□)と、クロスバーネットワーク301〜クロスバーネットワーク312と、ローカルメモリ201〜ローカルメモリ203を備えている。
そして、階層型マルチコアプロセッサ102では、ローカルメモリ203がメインCPU101と接続され、クロスバーネットワーク301とバス107が接続されている。メインCPU101と階層型マルチコアプロセッサ102のCPUとは直接接続されていない。メインCPU101が何らかの情報を階層型マルチコアプロセッサ102のCPUへ受け渡したり、階層型マルチコアプロセッサ102のCPUから何らかの情報を受け取るにはローカルメモリ203やメモリ105を介して行う。つぎに、階層型マルチコアプロセッサ102およびメインCPU101(点線の囲い)について詳細に説明する。
図2は、階層型マルチコアプロセッサ102とメインCPU101との3次元イメージ図である。まず、図2において、z方向が階層を表している。z方向においては、通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにCPU群を有していることを示している。通信プロトコルとは、通信におけるルールである。
ここで、一連の通信機能を構成する階層群とは、たとえば、後述するOSI参照モデルのうちプログラムにより実現される階層である。たとえば、z=0のCPU群がセッション層のプロトコルに沿って処理を実行し、z=1のCPU群がプレゼンテーション層のプロトコルに沿って処理を実行し、z=2のCPU群がアプリケーション層のプロトコルに沿って処理を実行する。
階層群のうち一の階層のCPU群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のCPU群に接続され、一の階層のCPU群が、当該一の階層の通信機能に続いて実行されない通信機能を構成する別の階層のCPU群とは接続されない。
セッション層のCPU群(z=0のCPU群)は、セッション層の通信機能に続いて実行されるプレゼンテーション層のCPU群(z=1のCPU群)にローカルメモリ201を介して接続されている。セッション層のCPU群(z=0のCPU群)は、セッション層の通信機能に続いて実行されないアプリケーション層のCPU群(z=2のCPU群)とは接続されない。すなわち、セッション層のCPU群(z=0のCPU群)は、アプリケーション層のCPU群(z=2のCPU群)とはプレゼンテーション層のCPU群を介して接続されている。
プレゼンテーション層のプロトコルに関する処理を実行するCPU群(z=1のCPU群)は、プレゼンテーション層の通信機能に続いて実行されるセッション層のCPU群(z=0のCPU群)にローカルメモリ201を介して接続されている。さらに、プレゼンテーション層の機能を実行するCPU群(z=1のCPU群)は、プレゼンテーション層の通信機能に続いて実行されるアプリケーション層のCPU群(z=2のCPU群)にローカルメモリ202を介して接続されている。
アプリケーション層のCPU群(z=2のCPU群)は、アプリケーション層の通信機能に続いて実行されるプレゼンテーション層のCPU群(z=1のCPU群)にローカルメモリ202を介して接続されている。さらに、アプリケーション層のCPU群(z=2のCPU群)は、プレゼンテーション層の通信機能に続いて実行されるアプリケーションのメインCPU101にローカルメモリ203を介して接続されている。
また、階層型マルチコアプロセッサ102の各CPUは、四則演算回路やビット演算回路(コア)で構成され、パケットのビットデータ処理に適した構成である。つぎに、y方向とx方向については図3を用いて説明する。
図3は、図2で示したAの詳細例を示す説明図である。各階層のCPU群は、複数のクラスタに分割されている。図3において、y方向により複数のクラスタが表されている。本実施の形態では、各階層のCPU群はクラスタ#0〜クラスタ#3の4つのクラスタに分割されている。各階層のCPU群は、各階層のクラスタ群とも言い換えることができる。
そして、各クラスタは、複数のCPUを有している。図3においてx方向によりクラスタが有する複数のCPUが表されている。本実施の形態では、各クラスタはCPU#0〜CPU#3の4つのCPUを有している。また、各クラスタのCPU#0は、コントロールプロセッサ(以下、「CP(Contorol Processor)」と称する。)であり、クラスタ内のCPUへのディスパッチを実行する。
また、各クラスタのCPU群はクロスバースイッチにより接続されている。たとえば、z=0において、クラスタ#0のCPU#0〜CPU#3がそれぞれクロスバーネットワーク301に接続され、クラスタ#1のCPU#0〜CPU#3がそれぞれクロスバーネットワーク302に接続されている。さらに、z=0において、クラスタ#2のCPU#0〜CPU#3がそれぞれクロスバーネットワーク303に接続され、クラスタ#3のCPU#0〜CPU#3がそれぞれクロスバーネットワーク304に接続されている。
クロスバーネットワーク301〜クロスバーネットワーク304はそれぞれローカルメモリ201に接続されている。本実施の形態では、メインCPU101が各クラスタに異なる通信機能を割り当てるように制御する。または、メインCPU101が複数のクラスタにまたがって一つの通信機能を割り当てないように制御するため、クラスタ間でのデータの受け渡しは発生しない。z=0において、もしクラスタ間でデータの受け渡しがある場合には、ローカルメモリ201を介して行われる。
また、たとえば、z=1において、クラスタ#0のCPU#0〜CPU#3がそれぞれクロスバーネットワーク305に接続され、クラスタ#1のCPU#0〜CPU#3がそれぞれクロスバーネットワーク306に接続されている。さらに、z=1において、クラスタ#2のCPU#0〜CPU#3がそれぞれクロスバーネットワーク307に接続され、クラスタ#3のCPU#0〜CPU#3がそれぞれクロスバーネットワーク308に接続されている。クロスバーネットワーク305〜クロスバーネットワーク308はそれぞれローカルメモリ201とローカルメモリ202に接続されている。
また、図3に示していないが、たとえば、z=2において、クラスタ#0のCPU#0〜CPU#3がそれぞれクロスバーネットワーク309に接続され、クラスタ#1のCPU#0〜CPU#3がそれぞれクロスバーネットワーク310に接続されている。さらに、z=2において、クラスタ#2のCPU#0〜CPU#3がそれぞれクロスバーネットワーク311に接続され、クラスタ#3のCPU#0〜CPU#3がそれぞれクロスバーネットワーク312に接続されている。クロスバーネットワーク309〜クロスバーネットワーク312はそれぞれローカルメモリ202とローカルメモリ203に接続されている。
また、各クラスタのCPが、各クラスタに割り当てられたプロトコルに関する処理を、各クラスタ内の複数のCPUに並列実行させるように制御する。通史機能に関する処理によっては、イタレーションがあるため、当該通信機能に関する処理が割り当てられたクラスタのCPUに該イタレーションを並列に実行させることで、スループットを向上することができる。つぎに、本実施の形態で用いる階層群を説明する。
図4は、本実施の形態で用いる階層群の一例を示す説明図である。本実施の形態においては、上述のように階層群としてOSI参照モデルを例に挙げて説明する。OSI参照モデルは、周知のように通信機能を階層構造に分割したモデルであって、第1層から第7層までの計7層構造で成り立っている。
OSI参照モデルの第1層は物理層であり、第2層はデータリンク層であり、第3層がネットワーク層であり、第4層がトランスポート層であり、第5層がセッション層であり、第6層がプレゼンテーション層であり、第7層がアプリケーション層である。本実施の形態では、OSI参照モデルに加えてUI(User Interface(ユーザーインターフェース))やアプリケーションプログラム(以下、「UI/アプリケーション」と称する。)をアプリケーション層のさらに上位の階層として挙げる。
物理層とデータリンク層の一部はインフラであり、データリンク層の一部とネットワーク層とトランスポート層とセッション層の一部はハードワイヤードで実現され、セッション層の一部とプレゼンテーション層とアプリケーション層とUI/アプリケーションとがプログラムにより実現され、該プログラムをCOUがロードして実行する。本実施の形態では、上述のようにセッション層のプロトコルに関する処理とプレゼンテーション層のプロトコルに処理とアプリケーション層のプロトコルに関する処理とUI/アプリケーションに関する処理を実行するCPUがあらかじめ決定されている。
セッション層のプロトコルに関する処理はz=0のCPU群で実行され、プレゼンテーション層のプロトコルに処理はz=1のCPU群で実行され、アプリケーション層のプロトコルに関する処理z=2のCPU群で実行され、UI/アプリケーションに関する処理はメインCPU101で実行される。
ここで、各層のプロトコル例を説明する。まず、セッション層のプロトコルとしては、たとえば、SSL(Secure Socket Layer)/TLS(Transport Layer Security)やRPC(Remote Procedure Call)が挙げられる。
つぎに、プレゼンテーション層のプロトコルとしては、たとえば、HTML(Hyper Text Markup Language)、XML(Extensible Markup Language)、AFP(Apple Filing Protocol)、SNMP(Simple Network Management Protocol)が挙げられる。
そして、アプリケーション層のプロトコルとしては、たとえば、HTTP(Hypertext Transfer Protocol)、EHRP(Endpoint Handlespace Redundancy Protocol)、9P、IMAP4(Internet Message Access Protocol)、NNTP(Network News Transfer Protocol)、CMIP(Common Management Information Protocol)、IRC(Internet Relay Chat)、Gopher、DHCP(Dynamic Host Configuration Protocol)、FTP(File Transfer Protocol)、GTP(GPRS(General Packet Radio Service) Tunneling Protocol)、DNS(Domain Name System)が挙げられる。
最後に、UI/アプリケーションは、携帯電話を例に挙げると、ブラウザ、VoIP(Voice over Internet Protocol)、仮想現実、テレフォニー、ダウンローダ、ゲーム、コミュニケーション、ネットリンク、ダイヤルアップ、メーラ、SNS(Social Networking Service)、P2P(Peer to Peer)が挙げられる。
ここで、UIは、電源投入後直ぐに起動される。一方、アプリケーションは利用者からの起動指示により起動されたり、外部要因によって起動される。外部要因とはメールの受信や電話の着信などが挙げられる。よって、メーラやダイヤルアップは電源投入後直ぐに実行待ち状態となるアプリケーションである。そして、メールの受信により直ぐにメーラが起動され、電話の着信により直ぐにダイヤルアップが起動される。
本実施の形態では、電源投入直後に実行待ち状態となる処理としてメーラの受信処理を例に挙げ、利用者からの起動指示により実行される処理としてブラウザに関する処理を例に挙げて説明する。メーラの受信処理を実行するには、たとえば、アプリケーション層のIMAP4とプレゼンテーション層のSNMPとセッション層のSSLとが利用される。ブラウザに関する処理を実行するには、たとえば、アプリケーション層のHTTPやFTPと、プレゼンテーション層のHTMLやXMLと、セッション層のTLSが利用される。
図2においてはz方向が階層を示し、y方向がクラスタを示し、x方向がクラスタ内のCPUを示していたが、図4においてはz方向が階層を示し、y方向がプロトコルを示し、x方向がプロトコルに関する並列処理を示している。図2および図4では、各階層のクラスタには当該階層に応じたプロトコルが割り当てられることを示し、各クラスタには、異なるプロトコルに関する処理を割り当てることを示し、プロトコルに関する処理を各クラスタ内の複数のコアに並列実行させることを示している。階層型マルチプロセッサ102の各クラスタは4つのCPUを有しているため、たとえば、FTPに関する処理が図4のように4つのタスクから構成されている場合、FTPに関する処理が割り当てられたクラスタのCPUごとにそれぞれのタスクを割り当てることができる。
図1に戻って、つぎに、メモリ105とメモリ106について説明する。メモリ106は、各種情報を記憶したり、通信CPU103のワークエリアとして使用される。メモリ105は、各種情報を記憶したり、メインCPU101のワークエリアとして使用される。メモリ105およびメモリ106は、具体的には、たとえば、ROM(Read Only Memory)、RAM(Random Access Memory)、フラッシュメモリ、ハードディスクドライブなどの記憶装置である。
図5は、メモリ105に記憶されているプログラム例を示す説明図である。メモリ105には、OS501と、アプリケーションプログラム504と、リンカ503と、プロセステーブル700とが記憶されている。OS501は、ライブラリ群502を有し、各階層のプロトコルに関する処理を階層に応じたクラスタ群に割り当てるように制御し、階層に応じたクラスタ群のうちどのクラスタに割り当てるかを、プロセステーブル700を用いて制御する機能を有する。
ライブラリ群502は、ライブラリの集合である。ライブラリとは、汎用性の高い複数のプログラム部品をファイル化したプログラムであり、アプリケーションプログラム504などOS501上で動作する他のプログラムの一部として動作する。ライブラリ単独では実行することはできない。
アプリケーションプログラム504とOS501は、メインCPU101にロードされることで、コーディングされている処理をメインCPU101に実行させることとなる。すなわち、各階層のプロトコルに関する処理を階層に応じたCPUクラスタ群のうちどのクラスタに割り当てるかを、プロセステーブル700を用いて制御する処理をメインCPU101が実行することとなる。
また、図示していないが、各クラスタに割り当てられたプロトコルに関する処理を、各クラスタ内の複数のCPUに並列実行させるように制御する機能を有するプログラムがメモリ105に記憶されている。そして、該プログラムは、階層型マルチコアプロセッサ101の各クラスタのCPにロードされることで、コーディングされている処理を階層型マルチコアプロセッサ101の各クラスタのCPに実行させることとなる。
図6は、ライブラリ群502の一例を示す説明図である。ライブラリ群502は、プロトコルのライブラリ群やプロトコルのライブラリでないその他のライブラリ群604を有し、メモリ105に記憶されている。プロトコルのライブラリ群は、セッション層のライブラリ群601とプレゼンテーション層のライブラリ群602とアプリケーション層のライブラリ群603の階層ごとに3つのライブラリ群に分類されている。よって、メインCPU101は各プロトコルのライブラリがどの階層のプロトコルであるかを特定することができる。
セッション層のライブラリ群601には、たとえば、SSLのライブラリやTLSのライブラリやドライバのライブラリが属し、プレゼンテーション層のライブラリ群602には、たとえば、HTMLのライブラリやXMLのライブラリが属し、アプリケーション層のライブラリ群603には、たとえば、IMAP4のライブラリやFTPのライブラリが属している。
図5に戻って、リンカ503は、アプリケーションプログラム504とそのアプリケーションプログラム504で利用されるライブラリをリンクさせるプログラムである。アプリケーションプログラム504は、OS501上で動作するプログラムであり、必要に応じてライブラリを呼び出して処理を実行する。ブラウザを例に挙げると、リンカ503がライブラリ群からHTTPのライブラリと、FTPのライブラリと、HTMLのライブラリと、XMLのライブラリと、TLSのライブラリとをリンクさせる。リンカ503がリンクすることにより特定されるライブラリを実行オブジェクトと称する。
プロセステーブル700は、階層ごとに各階層のプロトコルに関する処理を実行するCPU群にどのプロトコルがどのクラスタのいくつのCPUに割り当てられているか(割り当て状態)、または割り当てられる予定であるか(割り当て予定)を示している。
図7は、プロセステーブル700の一例を示す説明図である。プロセステーブル700では、電源投入直後の割り当て状態および割り当て予定を示している。「Application_Layer:」と「Presentation_Layer:」と「Session_Layer:」の3つに分類されている。「Application_Layer:」がアプリケーション層に対応するCPU群への割り当て状態または割り当て予定を示している。「Presentation_Layer:」がプレゼンテーション層に対応するCPU群への割り当て状態または割り当て予定を示している。「Session_Layer:」がセッション層に対応するCPU群への割り当て状態または割り当て予定を示している。よって、各層の名称により図2に示すz方向を示している。
各層の割り当て状態および割り当て予定では、全クラスタ数がクラスタの数を示し、図3に示すy方向を示している。CPU数が各クラスタのCPU数を示し、図4に示すx方向を示している。図4に示したようにz=0において、クラスタ#0〜クラスタ#3であるため「全クラスタ数=4」であり、各クラスタはCPU#0〜CPU#3であるため「CPU数=4」である。
電源投入直後のプロセステーブル700は、実行待ち状態のアプリケーションや実行中のアプリケーションがまだ無いため、すべてのクラスタに何も割り当てられていない。「Off」はクラスタ内の全CPUがオフ状態であることを示している。オフ状態とは、クロックまたはパワーが供給されていない状態を指す。一方、オン状態とは、クロックおよびパワーが供給されている状態を指す。また、階層型マルチコアプロセッサ102には通常モードと低消費電力モードの2つのモードがあり、低消費電力モードは、たとえば、CPUへ供給されるクロックの周波数が下げられている状態を指す。
また、階層型マルチコアプロセッサ102のうちクロスバーネットワークおよびメインCPU101のみがバスに接続されているため、階層型マルチコアプロセッサ102のCPUのうちz=0のクラスタ#0のCPUを除く残余のCPUはプロトコルのライブラリやプロセステーブル700を直接参照できない。ライブラリの場合、z=0のクラスタ#0のCPまたはメインCPU101がプロトコルのライブラリを複製し、複製したライブラリを各クラスタのCPがアクセス可能なローカルメモリへ転送させる。
z=1のクラスタ#1のCPがHTTPのライブラリをロードおよびマッピングする場合を例に挙げて説明する。まず、z=0のクラスタ#0のCPがクロスバーネットワークを介してメモリ105へアクセスしてライブラリ群502のアプリケーション層のライブラリ群603からHTTPのライブラリを特定し、特定したHTPPのライブラリを複製する。そして、z=0のクラスタ#0のCPが、複製したHTTPのライブラリをローカルメモリ201へ転送する。つづいて、z=1のクラスタ#1のCPがクロスバーネットワーク305を介してローカルメモリ201にアクセスし、転送されたHTTPのライブラリをロードおよびマッピングする。
ここで、電源投入直後におけるマルチコアプロセッサの制御処理手順と制御処理手順を示し、つぎに、運用時に利用者からアプリケーションの起動指示を受け付けた場合のマルチコアプロセッサの制御処理手順と制御処理手順を示す。
(電源投入直後におけるメインCPU101による制御処理手順)
図8は、電源投入直後におけるメインCPU101による制御処理手順を示すフローチャートである。まず、メインCPU101が、起動準備が必要なアプリケーションのうち未選択のアプリケーションがあるか否かを判断する(ステップS801)。電源投入直後に起動準備が必要なアプリケーションとは、上述のようにメーラやダイヤルアップが挙げられる。
図8は、電源投入直後におけるメインCPU101による制御処理手順を示すフローチャートである。まず、メインCPU101が、起動準備が必要なアプリケーションのうち未選択のアプリケーションがあるか否かを判断する(ステップS801)。電源投入直後に起動準備が必要なアプリケーションとは、上述のようにメーラやダイヤルアップが挙げられる。
起動準備が必要なアプリケーションのうち未選択のアプリケーションがあると判断された場合(ステップS801:Yes)、未選択のアプリケーションの中から任意のアプリケーションを選択する(ステップS802)。つぎに、メインCPU101が、選択されたアプリケーションに関するライブラリをリンカによりリンクすることで、実行オブジェクトを特定する(ステップS803)。
そして、メインCPU101が、プロセステーブルを読み出し(ステップS804)、実行オブジェクトの階層に対応する階層のクラスタ群から実行オブジェクトを割り当てるクラスタを決定する(ステップS805)。ここでは、実行オブジェクト(ライブラリ)に記述されているコードの処理が割り当てられることを省略し、実行オブジェクト(ライブラリ)が割り当てられると称している。具体的には、たとえば、メインCPU101が、各クラスタの負荷量を集約して割り当てるクラスタを決定する。
つぎに、メインCPU101が、決定結果をプロセステーブルに登録し(ステップS806)、i=4とし(ステップS807)、第i層の実行オブジェクトの中で未選択の実行オブジェクトがあるか否かを判断する(ステップS808)。メインCPU101が、第i層の実行オブジェクトの中で未選択の実行オブジェクトがあると判断した場合(ステップS808:Yes)、未選択の実行オブジェクトの中から任意の実行オブジェクトを選択する(ステップS809)。そして、メインCPU101が、実行オブジェクトが割り当てられたクラスタのCPへ起動準備指示を通知し(ステップS810)、起動準備完了の通知を受け付けたか否かを判断する(ステップS811)。
メインCPU101が、起動準備完了の通知を受け付けていないと判断した場合(ステップS811:No)、ステップS811へ戻る。一方、メインCPU101が、起動準備完了の通知を受け付けたと判断した場合(ステップS811:Yes)、ステップS808へ戻る。また、メインCPU101が、第i層の実行オブジェクトの中で未選択の実行オブジェクトがないと判断した場合(ステップS808:No)、i=7であるか否かを判断する(ステップS812)。そして、i=7でないと判断した場合(ステップS812:No)、i=i+1とし(ステップS813)、ステップS808へ戻る。
一方、メインCPU101が、i=7であると判断した場合(ステップS812:Yes)、ステップS801へ戻る。つぎに、メインCPU101が、起動準備が必要なアプリケーションのうち未選択のアプリケーションがないと判断した場合(ステップS801:No)、運用を開始し(ステップS814)、一連の処理を終了する。
図9は、電源投入直後のCPによる制御処理手順を示すフローチャートである。まず、実行オブジェクトが割り当てられたクラスタのCP(図9の説明では省略して「CP」と称する。)が、メインCPUからの実行オブジェクトの起動準備指示を受け付けたか否かを判断する(ステップS901)。実行オブジェクトの起動準備とは、実行オブジェクト(ライブラリ)にコーディングされている処理(以降、「実行オブジェクトに関する処理」または「ライブラリに関する処理」と称する。)を直ぐに実行可能な状態にすることを指す。なお、本実施の形態においてプロトコルのライブラリに関する処理とプロトコルに関する処理は同一の意味で用いている。
CPが、メインCPUからの実行オブジェクトの起動準備指示を受け付けていないと判断した場合(ステップS901:No)、ステップS901へ戻る。一方、CPが、実行オブジェクトの起動準備指示を受け付けたと判断した場合(ステップS901:Yes)、実行オブジェクトをローカルメモリ上にマッピングし、実行オブジェクトのコンテキスト情報を生成する(ステップS902)。コンテキスト情報は周知のようにプログラムの内部状態やプログラムがメモリ上のどこに配置されたかを示す。ここでは、実行オブジェクトに関する処理が、該実行オブジェクトを割り当てられたクラスタがアクセス可能なローカルメモリ上にマッピングされ、ローカルメモリ上のどこにマッピングされているかを示す情報がコンテキスト情報として生成される。
そして、CPが、コンテキスト情報をレディキューに登録すると(ステップS903)、起動準備完了をメインCPUへ通知し(ステップS904)、一連の処理を終了する。レディキューとは、周知のように実行できる状態のタスクを管理するためのデータ構造である。CPはレディキューに登録されている実行オブジェクトのコンテキスト情報を取り出すことで、実行オブジェクトに関する処理を直ぐに実行することができる。すなわち、電源投入直後に起動準備が必要なアプリケーションは待ち受け状態となっている。
図10は、起動準備状態である実行オブジェクトの起動指示を受け付けたCPによる制御処理手順を示すフローチャートである。まず、起動準備状態である実行オブジェクトが割り当てられているクラスタのCP(図10の説明では省略して「CP」と称する。)が、下層から実行オブジェクトの起動指示を受け付けたか否かを判断する(ステップS1001)。実行オブジェクトの起動指示とは、実行オブジェクトに関する処理の起動指示を指している。まず、CPが、下層から実行オブジェクトの起動指示を受け付けていないと判断した場合(ステップS1001:No)、ステップS1001へ戻る。
一方、CPが、下層から実行オブジェクトの起動指示を受け付けたと判断した場合(ステップS1001:Yes)、起動指示を受け付けた実行オブジェクトに関する処理の実効レートを取得する(ステップS1002)。実効レートは帯域であり、CPは「Ping」コマンドにより取得することができる。
CPが、実行オブジェクトに関する処理の実行レート[bps(bit per second)]とCPUの処理能力[bps]からCPU数を算出し(ステップS1003)、算出したCPU数をプロセステーブルへ登録する(ステップS1004)。ここで、プロセステーブルへの登録について説明する。z=0のクラスタ#0のCPUとメインCPU101の場合、メモリ105へアクセスして直接プロセステーブル700に登録する。階層型マルチコアプロセッサ102のCPUのうちz=0のクラスタ#0のCPUを除く残余のCPUについては、z=0のクラスタ#0のCPUまたはメインCPU101へプロセステーブル700に算出したCPU数を登録するように通知する。
そして、CPが、不要CPUを停止し(ステップS1005)、レディキューから実行オブジェクトのコンテキスト情報を取得し(ステップS1006)、実行オブジェクトに関する処理を実行する(ステップS1007)。ここで、不要CPUとは、たとえば、クラスタ内の4つのCPUのうち3つのCPUを用いてプロトコルに関する処理を実行する場合、4つのCPUから3つのCPUを除く残余のCPUを指す。そして、CPが、ソケットを確立し(ステップS1008)、一連の処理を終了する。
図11は、起動準備が必要なアプリケーションの実行オブジェクトが終了する場合のCPによる制御処理手順を示すフローチャートである。起動準備が必要なアプリケーションの実行オブジェクトが割り当てられているクラスタのCP(図11の説明では省略して「CP」と称する。)が、当該起動準備が必要なアプリケーションの実行オブジェクトが終了したか否かを判断する(ステップS1101)。まず、CPが、起動準備が必要なアプリケーションの実行オブジェクトが終了していないと判断した場合(ステップS1101:No)、ステップS1101へ戻る。
つぎに、CPが、起動準備が必要なアプリケーションの実行オブジェクトが終了したと判断した場合(ステップS1101:Yes)、終了した実行オブジェクトのコンテキスト情報をレディキューに退避する(ステップS1102)。そして、CPが、不要CPUを停止し(ステップS1103)、プロセステーブルから終了した実行オブジェクトが割り当てられたクラスタのCPU数をリセットし(ステップS1104)、一連の処理を終了する。
(具体例1)
ここで、電源投入直後におけるマルチコアプロセッサシステム100の制御処理の具体例を説明する。
ここで、電源投入直後におけるマルチコアプロセッサシステム100の制御処理の具体例を説明する。
図12は、具体例1を示す説明図(その1)である。図12では、電源投入直後におけるメインCPU101による制御処理と、z=0のクラスタ#内のCPU#0(クラスタ#内のCP)による制御処理を示している。まず、起動準備が必要なアプリケーションとしてメーラとダイヤルアップなどが挙げられるが、ここでは、メーラの受信処理を例に説明する。
まず、メインCPU101が、リンカによりライブラリ群からメーラの受信処理に必要な実行オブジェクトを特定する。実行オブジェクトとしてSSLのライブラリとSNMPのライブラリとIMAP4のライブラリが特定される。図12では、SSLのライブラリを省略してSSLとし、SNMPのライブラリを省略してSNMPとし、IMAP4のライブラリを省略してIMAP4としている。
つぎに、メインCPU101がプロセステーブル700を読み出し、実行オブジェクトを割り当てるクラスタを決定し、決定結果をプロセステーブル700に登録する。メインCPU101が、たとえば、プロセステーブル700を参照すると何も割り当てられていないため、実行オブジェクトをどのクラスタに割り当ててもよい。また、実行オブジェクトが割り当てられたクラスタがオフ状態の場合、メインCPU101がそのクラスタをオン状態の低消費電力モードに切り替える。
図13は、具体例1において決定結果が登録された例を示す説明図である。IMAP4はアプリケーション層のプロトコルであるため、プロセステーブル1300では、IMAP4のライブラリが「Application_Layer:」のクラスタ#0に割り当て予定となっている。「CPU=#」では、プロトコルに関する処理をクラスタ#0のCPUのうちのいくつのCPUに割り当てるかが決定されていない状態を示している。
SNMPはプレゼンテーション層のプロトコルであるため、プロセステーブル1300では、SNMPのライブラリが「Presentation_Layer:」のクラスタ#0に割り当て予定となっている。SSLはセッション層のプロトコルであるため、プロセステーブル1300では、SSLのライブラリが「Session_Layer:」のクラスタ#0に割り当て予定となっている。
図12に戻って、つぎに、SSLに関する処理がz=0のクラスタ#0に割り当てられたため、z=0のクラスタ#0のCP(z=0のクラスタ#0のCPU#0)にSSLに関する処理の起動準備指示を通知する。そして、z=0のクラスタ#0のCPが、SSLに関する処理の起動準備指示を受け付けると、SSLに関する処理をローカルメモリ203(またはローカルメモリ202)にマッピングし、コンテキスト情報を生成する。
つぎに、z=0のクラスタ#0のCPU#0がSSLのコンテキスト情報をレディキュー1201に登録し、SSLに関する処理の起動準備が完了したことをメインCPU101へ通知する。なお、レディキュー1201は、たとえば、ローカルメモリ201に記憶されている。そして、メインCPU101が、SSLに関する処理の起動準備完了を受け付けると、SNMPに関する処理が割り当てられたz=1のクラスタ#0のCPU#0へ起動準備指示を通知する。さらに、メインCPU101が、SNMPに関する処理の起動準備完了を受け付けると、つぎに、IMAP4に関する処理が割り当てられたz=0のクラスタ#0のCPU#0へ起動準備指示を通知する。
図14は、具体例1を示す説明図(その2)である。図14では、図13につづいてSSLの起動指示を受け付けた場合の例を説明する。z=0のクラスタ#0のCPU#0が、SSLの起動指示を受け付けると、SSLに関する処理の実行レートを取得する。SSLに関する処理の実行レートが60[bps]であり、各CPUの処理能力が30[bps]であるとする。
z=0のクラスタ#0のCPU#0が、SSLに関する処理の実行レートを各CPUの処理能力で割ることによりSSLに関する処理に必要なCPU数を算出する。よって、SSLに関する処理に必要なCPU数は2である。つぎに、z=0のクラスタ#0のCPU#0が算出したCPU数をプロセステーブル1500に登録する。
図15は、具体例1において算出結果が登録された例を示す説明図である。プロセステーブル1500では、「Session_Layer:」のクラスタ#0に「SSL::CPU=2」が登録されている。
図14に戻って、つぎに、z=0のクラスタ#0のCPU#0が、不要CPUを停止し(オフ状態に切り替える)、SSLに関する処理が割り当てられたCPUを低消費電力モードから通常モードに切り替える。そして、z=0のクラスタ#0のCPU#0が、SSLのコンテキスト情報をレディキュー1201から取得してSSLに関する処理を実行し、ソケットを確立する。なお、SSLのコンテキスト情報はz=0のクラスタ#0のCPU#0により取得されるとともに、レディキュー1201から削除される。z=0のクラスタ#0のCPU#0はSSLに関する処理を実行すると、プレゼンテーション層のSNMPの起動指示を通知する。
また、SSLに関する処理の終了時、z=0のクラスタ#0のCPU#0はSSLのコンテキスト情報をレディキュー1201に退避し、不要CPUを停止する(オフ状態に切り替える)。そして、z=0のクラスタ#0のCPU#0はプロセステーブル1500を読み出し、SSLに割り当てられているCPU数をリセットする。つぎに、利用者からアプリケーションの起動指示をメインCPU101が受け付けた場合について説明する。
(マルチコアプロセッサシステム100のメインCPU101による制御処理手順)
図16は、アプリケーション起動時のメインCPU101による制御処理手順を示すフローチャートである。ここでは、メインCPU101が利用者からのアプリケーションの起動指示を受け付けた場合の制御処理手順について説明する。まず、メインCPU101が、アプリケーションプログラムの起動指示を受け付ける(ステップS1601)。
図16は、アプリケーション起動時のメインCPU101による制御処理手順を示すフローチャートである。ここでは、メインCPU101が利用者からのアプリケーションの起動指示を受け付けた場合の制御処理手順について説明する。まず、メインCPU101が、アプリケーションプログラムの起動指示を受け付ける(ステップS1601)。
つぎに、ステップS1602〜ステップS1608までは、それぞれステップS803〜ステップS809と同一処理であり、ステップS1611とステップS1612は、それぞれステップS812とステップS813と同一処理であるため、説明を省略する。ここでは、ステップS1609およびステップS1610とステップS1613〜ステップS1615について説明する。
まず、メインCPU101が、実行オブジェクトが割り当てられたクラスタのCPへ起動指示を通知し(ステップS1609)、起動完了の通知を受け付けたか否かを判断する(ステップS1610)。そして、メインCPU101が、起動完了の通知を受け付けていないと判断した場合(ステップS1610:No)、ステップS1610へ戻る。一方、起動完了の通知を受け付けたと判断した場合(ステップS1610:Yes)、ステップS1607へ戻る。
つぎに、ステップS1613において、メインCPU101が、アプリケーションのコンテキスト情報を生成し(ステップS1613)、通信層間のソケットを確立し(ステップS1614)、アプリケーションソフトウェアを起動し(ステップS1615)、一連の処理を終了する。
図17は、起動指示を受け付けたCPによる制御処理手順を示すフローチャートである。まず、実行オブジェクトが割り当てられたクラスタのCP(図17では省略してCPと称する。)が、メインCPUから実行オブジェクトの起動指示を受け付けたか否かを判断する(ステップS1701)。CPが、メインCPUから実行オブジェクトの起動指示を受け付けていないと判断した場合(ステップS1701:No)、ステップS1701へ戻る。
一方、CPが、メインCPUから実行オブジェクトの起動指示を受け付けたと判断した場合(ステップS1701:Yes)、起動指示を受け付けた実行オブジェクトのコンテキスト情報を生成し(ステップS1702)、コンテキスト情報をレディキューに登録する(ステップS1703)。つぎに、ステップS1704〜ステップS1710までは、それぞれステップS1002〜ステップS1008と同一処理であるため説明を省略する。そして、ステップS1710のつぎに、実行オブジェクトの起動完了をメインCPUへ通知し(ステップS1711)、一連の処理を終了する。
図18は、利用者の起動指示により起動したアプリケーションが終了する場合のCPによる制御処理手順を示すフローチャートである。利用者の起動指示により起動したアプリケーションであり、かつ電源投入直後に起動準備が必要でないアプリケーションの実行オブジェクトが割り当てられたクラスタのCP(図18では省略してCPと称する。)が、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了したか否かを判断する(ステップS1801)。
CPが、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了していないと判断した場合(ステップS1801:No)、ステップS1801へ戻る。一方、CPが、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了したと判断した場合(ステップS1801:Yes)、終了した実行オブジェクトのコンテキスト情報を削除する(ステップS1802)。
そして、CPが、不要CPUを停止し(ステップS1803)、プロセステーブルから終了した実行オブジェクトに関する記述を削除し(ステップS1804)、一連の処理を終了する。また、階層型マルチコアプロセッサ102のうちz=0のクラスタ#0のCPUを除く残余のCPUはプロセステーブルへ直接アクセスできないため、プロセステーブルへの登録処理と同様にプロセステーブルからの削除処理についてもメインCPU101かz=0のクラスタ#0のCPUへ実行オブジェクトに関する記述の削除を通知する。そして、メインCPU101またはz=0のクラスタ#0のCPUが削除処理を実行する。
(具体例2)
ここで、利用者からのアプリケーションの起動指示を受け付けた場合のマルチコアプロセッサシステムの制御処理の具体例を説明する。
ここで、利用者からのアプリケーションの起動指示を受け付けた場合のマルチコアプロセッサシステムの制御処理の具体例を説明する。
図19は、具体例2を示す説明図(その1)である。まず、メインCPU101がブラウザの起動指示を受け付け、リンカによりライブラリ群502からリンクして実行オブジェクトを特定する。ブラウザの実行オブジェクトとして、アプリケーション層のHTTPのライブラリおよびFTPのライブラリと、プレゼンテーション層のHTMLのライブラリと、セッション層のTLSのライブラリとが特定される。
そして、メインCPU101が、プロセステーブル1300を読み出し、特定した各実行オブジェクトを該実行オブジェクトの階層に対応する階層のクラスタ群からどのクラスタに割り当てるかを決定し、プロセステーブル1300に登録する。メインCPU101は、各階層のクラスタ群において各クラスタに異なる通信機能を割り当てるように制御する。
TLSのライブラリが割り当てられるクラスタの決定例を説明する。たとえば、プロセステーブル1300では、「Session_Layer:」においてクラスタ#0にSSLのライブラリが割り当てられ、クラスタ#1〜クラスタ#3には何も割り当てられていないことを示している。メインCPU101は、プロセステーブル1300を参照し、z=0のクラスタ群のうちSSLのライブラリが割り当てられているクラスタ#0を除く残余のクラスタからTLSのライブラリを割り当てるクラスタを決定する。ここでは、メインCPU101が、TLSのライブラリをクラスタ#1に割り当てると決定する。また、もし「Session_Layer:」のクラスタ#0〜クラスタ#3のすべてに割り当てられていることがプロセステーブル1300で示されている場合、たとえば、「CPU=」を参照してCPUが空いているクラスタを実行オブジェクトの割り当てクラスタに決定することとする。
図20は、具体例2において決定結果が登録された例を示す説明図である。プロセステーブル2000が、決定結果が登録された例である。TLSはセッション層のプロトコルであるため、プロセステーブル2000の「Session_Layer:」においてTLSがクラスタ#1に割り当てられていることが示されている。HTMLはプレゼンテーション層のプロトコルであるため、プロセステーブル2000の「Presentaion_Layer:」においてHTMLがクラスタ#1に割り当てられていることが示されている。HTTPおよびFTPはアプリケーション層のプロコルであるため、プロセステーブル2000の「Application_Layer:」においてHTTPがクラスタ#1に割り当てられていることが示され、FTPがクラスタ#2に割り当てられていることが示されている。
図19に戻って、メインCPU101が、プロセステーブル2000に決定結果を登録後、起動指示をそれぞれのプロトコルに関する処理が割り当てられたクラスタのCPへ通知する。ここで、メインCPU101は、下層のプロトコルに関する処理が割り当てられたクラスタのCPから順に上層のプロトコルに関する処理が割り当てられたクラスタのCPへ通知する。具体例2においては、まず、TLSに関する処理が割り当てられたz=0のクラスタ#1のCPへTLSに関する処理の起動指示を通知し、つぎに、HTMLに関する処理が割り当てられたz=1のクラスタ#1のCPへHTMLに関する処理の起動指示を通知する。そして、HTTPに関する処理が割り当てられたz=2のクラスタ#1のCPへHTTPに関する処理の起動指示を通知し、FTPに関する処理が割り当てられたz=2のクラスタ#2のCPへFTPに関する処理の起動指示を通知する。
図21は、具体例2を示す説明図(その2)である。TLSに関する処理は、z=0のクラスタ#1に割り当てられた。まず、z=0のクラスタ#1のCPが、CPUからの起動指示を受け付けると、TLSに関する処理をローカルメモリ上にマッピングしてコンテキスト情報を生成し、生成したTLSのコンテキスト情報をレディキュー2101に登録する。
つぎに、z=0のクラスタ#1のCPが、実行レートを取得し、取得した実行レートとクラスタ#1内のCPUの処理能力とに基づいてTLSに関する処理に必要なCPU数を算出する。ここで、取得した実行レートが120[bps]であり、階層型マルチコアプロセッサ102の各CPUの処理能力が30[bps]であると、TLSに関する処理に必要なCPU数は4つである。つぎに、z=0のクラスタ#1のCPが、プロセステーブル2000へ算出したCUP数(算出結果)を登録する。
図22は、具体例2において算出結果が登録された例を示す説明図である。プロセステーブル2200は、算出結果が登録された例である。プロセステーブル2200の「Session_Layer:」のクラスタ#1の行には、「TLS::CPU=4」と記述され、クラスタ#1の4つのCPUにTLSが割り当てられて並列に処理されることが示されている。
図21に戻って、z=0のクラスタ#1のCPが、レディキュー2101からTLSのコンテキスト情報を取得してTLSに関する処理を実行し、TLSのソケットを確立する。そして、z=0のクラスタ#1のCPがメインCPU101へTLSに関する処理の起動完了を通知し、メインCPU101がz=0のクラスタ#1のCPからのTLSに関する処理の起動完了を受け付けると、z=1のクラスタ#1のCPへHTMLに関する処理の起動指示を通知する。
また、具体例2で挙げたブラウザが終了する場合、ブラウザの実行オブジェクトが割り当てられたクラスタのCPが、該実行オブジェクトのコンテキスト情報を削除する。そして、プロセステーブル2200から終了した実行オブジェクトに関する記述を削除する。削除結果は、プロセステーブル1300と同一となる。
以上説明したように、階層型マルチコアプロセッサによれば、一連の通信機能を構成する階層群の階層ごとにCPU群を有している。そして、階層群のうち一の階層のCPU群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のCPU群に接続されることにより、CPU間の接続を減少させることができ、システムの大規模化を防止することができる。
また、各階層のコア群が複数のクラスタに分割されていることで、一の通信機能に関する処理を一のクラスタのコア群に実行させることができる。
また、各クラスタが複数のコアを有することで、一つの通信機能を並列に実行させることができ、スループットを向上させることができる。
以上説明したように、マルチコアプロセッサシステムおよび制御プログラムによれば、通信プロトコルの階層ごとにCPU群を有することで、一の通信機能に関する処理を一の通信機能の階層に応じた階層のCPU群に割り当てる。これにより、通信プロトコルを伴うアプリケーションソフトウェアの処理を効率的に実行することができる。
また、各階層のコア群が複数のクラスタに分割されている場合、同一階層の通信プロトコルに関する処理が同時に実行されても異なるCPUに割り当てることで各処理を効率的に実行することができる。
また、各クラスタが複数のCPUを有している場合、各クラスタに割り当てられた通信機能に関する処理を各クラスタ内の複数のコアに並列実行させることで、スループットを向上させることができる。
100 マルチコアプロセッサシステム
102 階層型マルチコアプロセッサ
102 階層型マルチコアプロセッサ
Claims (7)
- 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、
前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されることを特徴とする階層型マルチコアプロセッサ。 - 前記各階層のコア群は、複数のクラスタに分割されていることを特徴とする請求項1に記載の階層型マルチコアプロセッサ。
- 前記各クラスタは、複数のコアを有することを特徴とする請求項2に記載の階層型マルチコアプロセッサ。
- 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されている階層型マルチコアプロセッサと、
前記各階層のコア群に、当該階層に応じた通信機能を割り当てるように制御する制御手段と、
を備えることを特徴とするマルチコアプロセッサシステム。 - 前記階層型マルチコアプロセッサでは、前記各階層のコア群が複数のクラスタに分割されており、
前記制御手段では、前記各階層のコア群において分割された前記各クラスタに異なる通信機能を割り当てるように制御することを特徴とする請求項4に記載のマルチコアプロセッサシステム。 - 前記階層型マルチコアプロセッサでは、前記各クラスタが複数のコアを有しており、
前記制御手段では、前記各クラスタに割り当てられた通信機能に関する処理を、前記各クラスタ内の複数のコアに並列実行させることを特徴とする請求項5に記載のマルチコアプロセッサシステム。 - 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されている階層型マルチコアプロセッサを制御するコアに、
前記各階層のコア群に、当該階層に応じた通信機能を割り当てるように制御する制御工程、
を実行させることを特徴とする制御プログラム。
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2010/054607 WO2011114477A1 (ja) | 2010-03-17 | 2010-03-17 | 階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JPWO2011114477A1 true JPWO2011114477A1 (ja) | 2013-06-27 |
Family
ID=44648606
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012505384A Pending JPWO2011114477A1 (ja) | 2010-03-17 | 2010-03-17 | 階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US20130013892A1 (ja) |
JP (1) | JPWO2011114477A1 (ja) |
CN (1) | CN102812445A (ja) |
WO (1) | WO2011114477A1 (ja) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8959522B2 (en) | 2012-01-30 | 2015-02-17 | International Business Machines Corporation | Full exploitation of parallel processors for data processing |
US9405340B2 (en) * | 2013-06-27 | 2016-08-02 | Intel Corporation | Apparatus and method to implement power management of a processor |
US10031573B2 (en) | 2014-11-17 | 2018-07-24 | Mediatek, Inc. | Energy efficiency strategy for interrupt handling in a multi-cluster system |
CN105849670A (zh) * | 2014-11-17 | 2016-08-10 | 联发科技股份有限公司 | 能源效率的多重群集***及其操作 |
US9977699B2 (en) | 2014-11-17 | 2018-05-22 | Mediatek, Inc. | Energy efficient multi-cluster system and its operations |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06350670A (ja) * | 1993-06-07 | 1994-12-22 | Nippon Telegr & Teleph Corp <Ntt> | データ受信並列処理方法 |
JPH0888666A (ja) * | 1994-09-19 | 1996-04-02 | Kokusai Denshin Denwa Co Ltd <Kdd> | 通信プロトコルの並列処理のためのバッファ制御方法 |
JP2002533992A (ja) * | 1998-12-18 | 2002-10-08 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 無線通信装置のメッセージ送信方法及び装置 |
JP2004318750A (ja) * | 2003-04-21 | 2004-11-11 | Getronics Japan Ltd | データ変換装置及び方法 |
JP2005311920A (ja) * | 2004-04-23 | 2005-11-04 | Toshiba Corp | 通信装置、通信システム、および通信制御プログラム |
JP2008512950A (ja) * | 2004-09-10 | 2008-04-24 | カビウム・ネットワークス | パケットのキューイング、スケジューリングおよび順序づけ |
JP2008523729A (ja) * | 2004-12-13 | 2008-07-03 | インテル・コーポレーション | フロー割当て |
JP2008541605A (ja) * | 2005-05-11 | 2008-11-20 | ウィズネット インコーポレーテッド | 埋め込み型システムのための高速データ処理・通信方法及び装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH07105823B2 (ja) * | 1987-09-09 | 1995-11-13 | 松下電器産業株式会社 | 通信プロトコル制御装置 |
US7360067B2 (en) * | 2002-12-12 | 2008-04-15 | International Business Machines Corporation | Method and data processing system for microprocessor communication in a cluster-based multi-processor wireless network |
CN101535956A (zh) * | 2006-11-02 | 2009-09-16 | 日本电气株式会社 | 多处理器***、多处理器***中的***构成方法及其程序 |
CN101546276B (zh) * | 2008-03-26 | 2012-12-19 | 国际商业机器公司 | 多核环境下实现中断调度的方法及多核处理器 |
-
2010
- 2010-03-17 CN CN2010800654212A patent/CN102812445A/zh active Pending
- 2010-03-17 JP JP2012505384A patent/JPWO2011114477A1/ja active Pending
- 2010-03-17 WO PCT/JP2010/054607 patent/WO2011114477A1/ja active Application Filing
-
2012
- 2012-09-13 US US13/614,330 patent/US20130013892A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH06350670A (ja) * | 1993-06-07 | 1994-12-22 | Nippon Telegr & Teleph Corp <Ntt> | データ受信並列処理方法 |
JPH0888666A (ja) * | 1994-09-19 | 1996-04-02 | Kokusai Denshin Denwa Co Ltd <Kdd> | 通信プロトコルの並列処理のためのバッファ制御方法 |
JP2002533992A (ja) * | 1998-12-18 | 2002-10-08 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | 無線通信装置のメッセージ送信方法及び装置 |
JP2004318750A (ja) * | 2003-04-21 | 2004-11-11 | Getronics Japan Ltd | データ変換装置及び方法 |
JP2005311920A (ja) * | 2004-04-23 | 2005-11-04 | Toshiba Corp | 通信装置、通信システム、および通信制御プログラム |
JP2008512950A (ja) * | 2004-09-10 | 2008-04-24 | カビウム・ネットワークス | パケットのキューイング、スケジューリングおよび順序づけ |
JP2008523729A (ja) * | 2004-12-13 | 2008-07-03 | インテル・コーポレーション | フロー割当て |
JP2008541605A (ja) * | 2005-05-11 | 2008-11-20 | ウィズネット インコーポレーテッド | 埋め込み型システムのための高速データ処理・通信方法及び装置 |
Also Published As
Publication number | Publication date |
---|---|
CN102812445A (zh) | 2012-12-05 |
US20130013892A1 (en) | 2013-01-10 |
WO2011114477A1 (ja) | 2011-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111756811B (zh) | 一种分布式***的主动推送的方法、***、设备及介质 | |
CN108628684B (zh) | 一种基于dpdk的报文处理方法及计算机设备 | |
WO2019179453A1 (zh) | 虚拟机创建方法及装置 | |
CN110413822B (zh) | 离线图像结构化分析方法、装置、***和存储介质 | |
WO2011114477A1 (ja) | 階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム | |
JP7100154B6 (ja) | プロセッサコアのスケジューリング方法、装置、端末及び記憶媒体 | |
JP2005267118A (ja) | シングルプロセッサ向けosによる並列処理システムにおけるプロセッサ間通信システム及びプログラム | |
CN110933075B (zh) | 服务调用方法、装置、电子设备及存储介质 | |
WO2022170446A1 (zh) | 一种卫星链路信息确定方法及装置 | |
JP2004310298A (ja) | 情報処理システム、情報処理装置、セッション管理方法及びプログラム | |
WO2022257247A1 (zh) | 数据处理方法、装置及计算机可读存储介质 | |
JP2021121921A (ja) | 人工知能開発プラットフォームの管理方法及び装置、媒体 | |
JP2022031621A (ja) | インスタンス数を調整するための方法および装置、電子機器、記憶媒体並びにコンピュータプログラム | |
CN114296953B (zh) | 一种多云异构***及任务处理方法 | |
CN111200651A (zh) | 定时调用微服务的方法、***、设备和介质 | |
CN116719647B (zh) | 超算集群管理方法、装置、编排管理设备及超算集群 | |
CN116841952A (zh) | 核间通信***、方法、装置、设备、芯片及可读存储介质 | |
Hamerski et al. | Publish-subscribe programming for a NoC-based multiprocessor system-on-chip | |
WO2013101093A1 (en) | Initialization of multi-core processing system | |
CN113098960A (zh) | 服务运行方法、装置、服务器及存储介质 | |
JP4667299B2 (ja) | プロセス間通信方法 | |
Masinde et al. | MOBIGRID: a middleware for integrating mobile phone and grid computing | |
Aljabri et al. | Scheduling manager for mobile cloud using multi-agents | |
Babou et al. | HEC-NerveNet: A Resilient Edge Cloud Architecture for Beyond 5G Networks | |
TW200400437A (en) | Method and arrangement for virtual direct memory access |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131105 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140106 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140422 |