JPWO2011114477A1 - 階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラム - Google Patents

Abstract

マルチコアプロセッサシステム（１００）では、ＯＳＩ参照モデルのセッション層のプロトコルに関する処理をｚ＝０のＣＰＵ群が実行し、プレゼンテーション層のプロトコルに関する処理をｚ＝１のＣＰＵ群が実行し、アプリケーション層のプロトコルに関する処理をｚ＝２のＣＰＵ群が実行する。アプリケーションソフトウェアに関する処理をメインＣＰＵ（１０１）が実行する。ｚ＝０のＣＰＵ群はローカルメモリ（２０１）を介してｚ＝１のＣＰＵ群に接続され、ｚ＝１のＣＰＵ群はローカルメモリ（２０２）を介してｚ＝２のＣＰＵ群に接続され、ｚ＝２のＣＰＵ群はローカルメモリ（２０３）を介してメインＣＰＵ（１０１）に接続されている。パケットはＯＳＩ参照モデルの階層順に受け渡されるため、ｚ＝０のＣＰＵ群とｚ＝２のＣＰＵ群は直接接続されずにｚ＝１のＣＰＵ群を介してのみ接続されている。

Description

本発明は、通信機能に関する処理を実行する階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラムに関する。

従来、マルチコアプロセッサシステムにおいてＣＰＵ群を１つのクラスタとして、アプリケーションソフトウェア（以下、「アプリケーション」と称する。）ごとに各クラスタでアプリケーションを実行する技術（従来技術１）が知られている（たとえば、下記特許文献１，２参照。）。マルチコアプロセッサシステムにおいてすべてのＣＰＵを等価に接続するとシステムが大規模になるため、クラスタを階層構造とし、結線を最適化する技術（従来技術２）が知られている（たとえば、下記特許文献３参照。）。

特開２００７−１９９８５９号公報 特開２００２−３４２２９５号公報 特開平５−２０４８７６号公報

しかしながら、従来技術１では、１アプリケーションソフトウェアに関する処理に対して１クラスタを割り当てるため、同時実行するアプリケーションが増えると、クラスタも増やさなければならず、システムが大規模になる問題点があった。また、従来技術２では、クラスタが階層構造であっても同一階層のすべてのクラスタ間を相互に接続させる必要があり、システムが大規模になる問題点があった。

本発明は、上述した従来技術による問題点を解消するため、ＣＰＵ間の接続数を減らすことで、システムの大規模化を抑制することができる階層型マルチコアプロセッサを提供することを目的とする。

本発明の一観点によれば、通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続される階層型マルチコアプロセッサが提供される。

本階層型マルチコアプロセッサによれば、ＣＰＵ間の接続数を減らすことで、システムの大規模化を抑制することができるという効果を奏する。

マルチコアプロセッサシステムのハードウェア構成の一例を示すブロック図である。 階層型マルチコアプロセッサ１０２とメインＣＰＵ１０１との３次元イメージ図である。 図２で示したＡの詳細例を示す説明図である。 本実施の形態で用いる階層群の一例を示す説明図である。 メモリ１０５に記憶されているプログラム例を示す説明図である。 ライブラリ群５０２の一例を示す説明図である。 プロセステーブル７００の一例を示す説明図である。 電源投入直後におけるメインＣＰＵ１０１による制御処理手順を示すフローチャートである。 電源投入直後のＣＰによる制御処理手順を示すフローチャートである。 起動準備状態である実行オブジェクトの起動指示を受け付けたＣＰによる制御処理手順を示すフローチャートである。 起動準備が必要なアプリケーションの実行オブジェクトが終了する場合のＣＰによる制御処理手順を示すフローチャートである。 具体例１を示す説明図（その１）である。 具体例１において決定結果が登録された例を示す説明図である。 具体例１を示す説明図（その２）である。 具体例１において算出結果が登録された例を示す説明図である。 アプリケーション起動時のメインＣＰＵ１０１による制御処理手順を示すフローチャートである。 起動指示を受け付けたＣＰによる制御処理手順を示すフローチャートである。 利用者の起動指示により起動したアプリケーションが終了する場合のＣＰによる制御処理手順を示すフローチャートである。 具体例２を示す説明図（その１）である。 具体例２において決定結果が登録された例を示す説明図である。 具体例２を示す説明図（その２）である。 具体例２において算出結果が登録された例を示す説明図である。

以下に添付図面を参照して、本発明にかかる階層型マルチコアプロセッサ、マルチコアプロセッサシステム、および制御プログラムの好適な実施の形態を詳細に説明する。

（マルチコアプロセッサシステムのハードウェア構成）
図１は、マルチコアプロセッサシステムのハードウェア構成の一例を示すブロック図である。図１において、マルチコアプロセッサシステム１００は、メインＣＰＵ１０１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、階層型マルチコアプロセッサ１０２と、通信ＣＰＵ１０３と、ＲＦ１０４と、メモリ１０５と、メモリ１０６と、アンテナ１１０と、を有する。メインＣＰＵ１０１とメモリ１０５は、バス１０７により接続されている。そして、通信ＣＰＵ１０３とメモリ１０６はバス１０８により接続されている。バス１０７とバス１０８はブリッジ１０９を介して接続されている。

ここで、メインＣＰＵ１０１は、アプリケーションソフトウェアに関する処理の全体の制御を司るプロセッサであり、一次キャッシュが内蔵されている。通信ＣＰＵ１０３は、通信に関する処理の全体の制御を司るプロセッサである。なお、通信用の通信ＣＰＵ１０３とアプリケーション用のメインＣＰＵ１０１とを別個に持つ構成は周知である。

ＲＦ１０４は、高周波処理部であり、アンテナ１１０を介してインターネットなどのネットワークからデータを受信したり、該ネットワークへデータを送信したりする。ここでは、ＲＦ１０４は、Ａ（Ａｎａｌｏｇ）／Ｄ（Ｄｉｇｉｔａｌ）コンバータやＤ（Ｄｉｇｉｔａｌ）／Ａ（Ａｎａｌｏｇ）コンバータなどを備えていることとし、ネットワークからのデータをディジタル信号に変換したり、通信ＣＰＵ１０３からのデータをアナログ信号に変換したりする。

階層型マルチコアプロセッサ１０２は、通信ＣＰＵ１０３からのデータをメインＣＰＵ１０１で使用可能な状態に変換、またはメインＣＰＵ１０１からのデータを通信ＣＰＵ１０３で使用可能な状態に変換する。階層型マルチコアプロセッサ１０２は、ＣＰＵ群（図中□）と、クロスバーネットワーク３０１〜クロスバーネットワーク３１２と、ローカルメモリ２０１〜ローカルメモリ２０３を備えている。

そして、階層型マルチコアプロセッサ１０２では、ローカルメモリ２０３がメインＣＰＵ１０１と接続され、クロスバーネットワーク３０１とバス１０７が接続されている。メインＣＰＵ１０１と階層型マルチコアプロセッサ１０２のＣＰＵとは直接接続されていない。メインＣＰＵ１０１が何らかの情報を階層型マルチコアプロセッサ１０２のＣＰＵへ受け渡したり、階層型マルチコアプロセッサ１０２のＣＰＵから何らかの情報を受け取るにはローカルメモリ２０３やメモリ１０５を介して行う。つぎに、階層型マルチコアプロセッサ１０２およびメインＣＰＵ１０１（点線の囲い）について詳細に説明する。

図２は、階層型マルチコアプロセッサ１０２とメインＣＰＵ１０１との３次元イメージ図である。まず、図２において、ｚ方向が階層を表している。ｚ方向においては、通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにＣＰＵ群を有していることを示している。通信プロトコルとは、通信におけるルールである。

ここで、一連の通信機能を構成する階層群とは、たとえば、後述するＯＳＩ参照モデルのうちプログラムにより実現される階層である。たとえば、ｚ＝０のＣＰＵ群がセッション層のプロトコルに沿って処理を実行し、ｚ＝１のＣＰＵ群がプレゼンテーション層のプロトコルに沿って処理を実行し、ｚ＝２のＣＰＵ群がアプリケーション層のプロトコルに沿って処理を実行する。

階層群のうち一の階層のＣＰＵ群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のＣＰＵ群に接続され、一の階層のＣＰＵ群が、当該一の階層の通信機能に続いて実行されない通信機能を構成する別の階層のＣＰＵ群とは接続されない。

セッション層のＣＰＵ群（ｚ＝０のＣＰＵ群）は、セッション層の通信機能に続いて実行されるプレゼンテーション層のＣＰＵ群（ｚ＝１のＣＰＵ群）にローカルメモリ２０１を介して接続されている。セッション層のＣＰＵ群（ｚ＝０のＣＰＵ群）は、セッション層の通信機能に続いて実行されないアプリケーション層のＣＰＵ群（ｚ＝２のＣＰＵ群）とは接続されない。すなわち、セッション層のＣＰＵ群（ｚ＝０のＣＰＵ群）は、アプリケーション層のＣＰＵ群（ｚ＝２のＣＰＵ群）とはプレゼンテーション層のＣＰＵ群を介して接続されている。

プレゼンテーション層のプロトコルに関する処理を実行するＣＰＵ群（ｚ＝１のＣＰＵ群）は、プレゼンテーション層の通信機能に続いて実行されるセッション層のＣＰＵ群（ｚ＝０のＣＰＵ群）にローカルメモリ２０１を介して接続されている。さらに、プレゼンテーション層の機能を実行するＣＰＵ群（ｚ＝１のＣＰＵ群）は、プレゼンテーション層の通信機能に続いて実行されるアプリケーション層のＣＰＵ群（ｚ＝２のＣＰＵ群）にローカルメモリ２０２を介して接続されている。

アプリケーション層のＣＰＵ群（ｚ＝２のＣＰＵ群）は、アプリケーション層の通信機能に続いて実行されるプレゼンテーション層のＣＰＵ群（ｚ＝１のＣＰＵ群）にローカルメモリ２０２を介して接続されている。さらに、アプリケーション層のＣＰＵ群（ｚ＝２のＣＰＵ群）は、プレゼンテーション層の通信機能に続いて実行されるアプリケーションのメインＣＰＵ１０１にローカルメモリ２０３を介して接続されている。

また、階層型マルチコアプロセッサ１０２の各ＣＰＵは、四則演算回路やビット演算回路（コア）で構成され、パケットのビットデータ処理に適した構成である。つぎに、ｙ方向とｘ方向については図３を用いて説明する。

図３は、図２で示したＡの詳細例を示す説明図である。各階層のＣＰＵ群は、複数のクラスタに分割されている。図３において、ｙ方向により複数のクラスタが表されている。本実施の形態では、各階層のＣＰＵ群はクラスタ＃０〜クラスタ＃３の４つのクラスタに分割されている。各階層のＣＰＵ群は、各階層のクラスタ群とも言い換えることができる。

そして、各クラスタは、複数のＣＰＵを有している。図３においてｘ方向によりクラスタが有する複数のＣＰＵが表されている。本実施の形態では、各クラスタはＣＰＵ＃０〜ＣＰＵ＃３の４つのＣＰＵを有している。また、各クラスタのＣＰＵ＃０は、コントロールプロセッサ（以下、「ＣＰ（Ｃｏｎｔｏｒｏｌ Ｐｒｏｃｅｓｓｏｒ）」と称する。）であり、クラスタ内のＣＰＵへのディスパッチを実行する。

また、各クラスタのＣＰＵ群はクロスバースイッチにより接続されている。たとえば、ｚ＝０において、クラスタ＃０のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０１に接続され、クラスタ＃１のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０２に接続されている。さらに、ｚ＝０において、クラスタ＃２のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０３に接続され、クラスタ＃３のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０４に接続されている。

クロスバーネットワーク３０１〜クロスバーネットワーク３０４はそれぞれローカルメモリ２０１に接続されている。本実施の形態では、メインＣＰＵ１０１が各クラスタに異なる通信機能を割り当てるように制御する。または、メインＣＰＵ１０１が複数のクラスタにまたがって一つの通信機能を割り当てないように制御するため、クラスタ間でのデータの受け渡しは発生しない。ｚ＝０において、もしクラスタ間でデータの受け渡しがある場合には、ローカルメモリ２０１を介して行われる。

また、たとえば、ｚ＝１において、クラスタ＃０のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０５に接続され、クラスタ＃１のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０６に接続されている。さらに、ｚ＝１において、クラスタ＃２のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０７に接続され、クラスタ＃３のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０８に接続されている。クロスバーネットワーク３０５〜クロスバーネットワーク３０８はそれぞれローカルメモリ２０１とローカルメモリ２０２に接続されている。

また、図３に示していないが、たとえば、ｚ＝２において、クラスタ＃０のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３０９に接続され、クラスタ＃１のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３１０に接続されている。さらに、ｚ＝２において、クラスタ＃２のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３１１に接続され、クラスタ＃３のＣＰＵ＃０〜ＣＰＵ＃３がそれぞれクロスバーネットワーク３１２に接続されている。クロスバーネットワーク３０９〜クロスバーネットワーク３１２はそれぞれローカルメモリ２０２とローカルメモリ２０３に接続されている。

また、各クラスタのＣＰが、各クラスタに割り当てられたプロトコルに関する処理を、各クラスタ内の複数のＣＰＵに並列実行させるように制御する。通史機能に関する処理によっては、イタレーションがあるため、当該通信機能に関する処理が割り当てられたクラスタのＣＰＵに該イタレーションを並列に実行させることで、スループットを向上することができる。つぎに、本実施の形態で用いる階層群を説明する。

図４は、本実施の形態で用いる階層群の一例を示す説明図である。本実施の形態においては、上述のように階層群としてＯＳＩ参照モデルを例に挙げて説明する。ＯＳＩ参照モデルは、周知のように通信機能を階層構造に分割したモデルであって、第１層から第７層までの計７層構造で成り立っている。

ＯＳＩ参照モデルの第１層は物理層であり、第２層はデータリンク層であり、第３層がネットワーク層であり、第４層がトランスポート層であり、第５層がセッション層であり、第６層がプレゼンテーション層であり、第７層がアプリケーション層である。本実施の形態では、ＯＳＩ参照モデルに加えてＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ（ユーザーインターフェース））やアプリケーションプログラム（以下、「ＵＩ／アプリケーション」と称する。）をアプリケーション層のさらに上位の階層として挙げる。

物理層とデータリンク層の一部はインフラであり、データリンク層の一部とネットワーク層とトランスポート層とセッション層の一部はハードワイヤードで実現され、セッション層の一部とプレゼンテーション層とアプリケーション層とＵＩ／アプリケーションとがプログラムにより実現され、該プログラムをＣＯＵがロードして実行する。本実施の形態では、上述のようにセッション層のプロトコルに関する処理とプレゼンテーション層のプロトコルに処理とアプリケーション層のプロトコルに関する処理とＵＩ／アプリケーションに関する処理を実行するＣＰＵがあらかじめ決定されている。

セッション層のプロトコルに関する処理はｚ＝０のＣＰＵ群で実行され、プレゼンテーション層のプロトコルに処理はｚ＝１のＣＰＵ群で実行され、アプリケーション層のプロトコルに関する処理ｚ＝２のＣＰＵ群で実行され、ＵＩ／アプリケーションに関する処理はメインＣＰＵ１０１で実行される。

ここで、各層のプロトコル例を説明する。まず、セッション層のプロトコルとしては、たとえば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）／ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）やＲＰＣ（Ｒｅｍｏｔｅ Ｐｒｏｃｅｄｕｒｅ Ｃａｌｌ）が挙げられる。

つぎに、プレゼンテーション層のプロトコルとしては、たとえば、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）、ＡＦＰ（Ａｐｐｌｅ Ｆｉｌｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）が挙げられる。

そして、アプリケーション層のプロトコルとしては、たとえば、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＥＨＲＰ（Ｅｎｄｐｏｉｎｔ Ｈａｎｄｌｅｓｐａｃｅ Ｒｅｄｕｎｄａｎｃｙ Ｐｒｏｔｏｃｏｌ）、９Ｐ、ＩＭＡＰ４（Ｉｎｔｅｒｎｅｔ Ｍｅｓｓａｇｅ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）、ＮＮＴＰ（Ｎｅｔｗｏｒｋ Ｎｅｗｓ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＣＭＩＰ（Ｃｏｍｍｏｎ Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＩＲＣ（Ｉｎｔｅｒｎｅｔ Ｒｅｌａｙ Ｃｈａｔ）、Ｇｏｐｈｅｒ、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＧＴＰ（ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ） Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）が挙げられる。

最後に、ＵＩ／アプリケーションは、携帯電話を例に挙げると、ブラウザ、ＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、仮想現実、テレフォニー、ダウンローダ、ゲーム、コミュニケーション、ネットリンク、ダイヤルアップ、メーラ、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）、Ｐ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）が挙げられる。

ここで、ＵＩは、電源投入後直ぐに起動される。一方、アプリケーションは利用者からの起動指示により起動されたり、外部要因によって起動される。外部要因とはメールの受信や電話の着信などが挙げられる。よって、メーラやダイヤルアップは電源投入後直ぐに実行待ち状態となるアプリケーションである。そして、メールの受信により直ぐにメーラが起動され、電話の着信により直ぐにダイヤルアップが起動される。

本実施の形態では、電源投入直後に実行待ち状態となる処理としてメーラの受信処理を例に挙げ、利用者からの起動指示により実行される処理としてブラウザに関する処理を例に挙げて説明する。メーラの受信処理を実行するには、たとえば、アプリケーション層のＩＭＡＰ４とプレゼンテーション層のＳＮＭＰとセッション層のＳＳＬとが利用される。ブラウザに関する処理を実行するには、たとえば、アプリケーション層のＨＴＴＰやＦＴＰと、プレゼンテーション層のＨＴＭＬやＸＭＬと、セッション層のＴＬＳが利用される。

図２においてはｚ方向が階層を示し、ｙ方向がクラスタを示し、ｘ方向がクラスタ内のＣＰＵを示していたが、図４においてはｚ方向が階層を示し、ｙ方向がプロトコルを示し、ｘ方向がプロトコルに関する並列処理を示している。図２および図４では、各階層のクラスタには当該階層に応じたプロトコルが割り当てられることを示し、各クラスタには、異なるプロトコルに関する処理を割り当てることを示し、プロトコルに関する処理を各クラスタ内の複数のコアに並列実行させることを示している。階層型マルチプロセッサ１０２の各クラスタは４つのＣＰＵを有しているため、たとえば、ＦＴＰに関する処理が図４のように４つのタスクから構成されている場合、ＦＴＰに関する処理が割り当てられたクラスタのＣＰＵごとにそれぞれのタスクを割り当てることができる。

図１に戻って、つぎに、メモリ１０５とメモリ１０６について説明する。メモリ１０６は、各種情報を記憶したり、通信ＣＰＵ１０３のワークエリアとして使用される。メモリ１０５は、各種情報を記憶したり、メインＣＰＵ１０１のワークエリアとして使用される。メモリ１０５およびメモリ１０６は、具体的には、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、フラッシュメモリ、ハードディスクドライブなどの記憶装置である。

図５は、メモリ１０５に記憶されているプログラム例を示す説明図である。メモリ１０５には、ＯＳ５０１と、アプリケーションプログラム５０４と、リンカ５０３と、プロセステーブル７００とが記憶されている。ＯＳ５０１は、ライブラリ群５０２を有し、各階層のプロトコルに関する処理を階層に応じたクラスタ群に割り当てるように制御し、階層に応じたクラスタ群のうちどのクラスタに割り当てるかを、プロセステーブル７００を用いて制御する機能を有する。

ライブラリ群５０２は、ライブラリの集合である。ライブラリとは、汎用性の高い複数のプログラム部品をファイル化したプログラムであり、アプリケーションプログラム５０４などＯＳ５０１上で動作する他のプログラムの一部として動作する。ライブラリ単独では実行することはできない。

アプリケーションプログラム５０４とＯＳ５０１は、メインＣＰＵ１０１にロードされることで、コーディングされている処理をメインＣＰＵ１０１に実行させることとなる。すなわち、各階層のプロトコルに関する処理を階層に応じたＣＰＵクラスタ群のうちどのクラスタに割り当てるかを、プロセステーブル７００を用いて制御する処理をメインＣＰＵ１０１が実行することとなる。

また、図示していないが、各クラスタに割り当てられたプロトコルに関する処理を、各クラスタ内の複数のＣＰＵに並列実行させるように制御する機能を有するプログラムがメモリ１０５に記憶されている。そして、該プログラムは、階層型マルチコアプロセッサ１０１の各クラスタのＣＰにロードされることで、コーディングされている処理を階層型マルチコアプロセッサ１０１の各クラスタのＣＰに実行させることとなる。

図６は、ライブラリ群５０２の一例を示す説明図である。ライブラリ群５０２は、プロトコルのライブラリ群やプロトコルのライブラリでないその他のライブラリ群６０４を有し、メモリ１０５に記憶されている。プロトコルのライブラリ群は、セッション層のライブラリ群６０１とプレゼンテーション層のライブラリ群６０２とアプリケーション層のライブラリ群６０３の階層ごとに３つのライブラリ群に分類されている。よって、メインＣＰＵ１０１は各プロトコルのライブラリがどの階層のプロトコルであるかを特定することができる。

セッション層のライブラリ群６０１には、たとえば、ＳＳＬのライブラリやＴＬＳのライブラリやドライバのライブラリが属し、プレゼンテーション層のライブラリ群６０２には、たとえば、ＨＴＭＬのライブラリやＸＭＬのライブラリが属し、アプリケーション層のライブラリ群６０３には、たとえば、ＩＭＡＰ４のライブラリやＦＴＰのライブラリが属している。

図５に戻って、リンカ５０３は、アプリケーションプログラム５０４とそのアプリケーションプログラム５０４で利用されるライブラリをリンクさせるプログラムである。アプリケーションプログラム５０４は、ＯＳ５０１上で動作するプログラムであり、必要に応じてライブラリを呼び出して処理を実行する。ブラウザを例に挙げると、リンカ５０３がライブラリ群からＨＴＴＰのライブラリと、ＦＴＰのライブラリと、ＨＴＭＬのライブラリと、ＸＭＬのライブラリと、ＴＬＳのライブラリとをリンクさせる。リンカ５０３がリンクすることにより特定されるライブラリを実行オブジェクトと称する。

プロセステーブル７００は、階層ごとに各階層のプロトコルに関する処理を実行するＣＰＵ群にどのプロトコルがどのクラスタのいくつのＣＰＵに割り当てられているか（割り当て状態）、または割り当てられる予定であるか（割り当て予定）を示している。

図７は、プロセステーブル７００の一例を示す説明図である。プロセステーブル７００では、電源投入直後の割り当て状態および割り当て予定を示している。「Ａｐｐｌｉｃａｔｉｏｎ＿Ｌａｙｅｒ：」と「Ｐｒｅｓｅｎｔａｔｉｏｎ＿Ｌａｙｅｒ：」と「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」の３つに分類されている。「Ａｐｐｌｉｃａｔｉｏｎ＿Ｌａｙｅｒ：」がアプリケーション層に対応するＣＰＵ群への割り当て状態または割り当て予定を示している。「Ｐｒｅｓｅｎｔａｔｉｏｎ＿Ｌａｙｅｒ：」がプレゼンテーション層に対応するＣＰＵ群への割り当て状態または割り当て予定を示している。「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」がセッション層に対応するＣＰＵ群への割り当て状態または割り当て予定を示している。よって、各層の名称により図２に示すｚ方向を示している。

各層の割り当て状態および割り当て予定では、全クラスタ数がクラスタの数を示し、図３に示すｙ方向を示している。ＣＰＵ数が各クラスタのＣＰＵ数を示し、図４に示すｘ方向を示している。図４に示したようにｚ＝０において、クラスタ＃０〜クラスタ＃３であるため「全クラスタ数＝４」であり、各クラスタはＣＰＵ＃０〜ＣＰＵ＃３であるため「ＣＰＵ数＝４」である。

電源投入直後のプロセステーブル７００は、実行待ち状態のアプリケーションや実行中のアプリケーションがまだ無いため、すべてのクラスタに何も割り当てられていない。「Ｏｆｆ」はクラスタ内の全ＣＰＵがオフ状態であることを示している。オフ状態とは、クロックまたはパワーが供給されていない状態を指す。一方、オン状態とは、クロックおよびパワーが供給されている状態を指す。また、階層型マルチコアプロセッサ１０２には通常モードと低消費電力モードの２つのモードがあり、低消費電力モードは、たとえば、ＣＰＵへ供給されるクロックの周波数が下げられている状態を指す。

また、階層型マルチコアプロセッサ１０２のうちクロスバーネットワークおよびメインＣＰＵ１０１のみがバスに接続されているため、階層型マルチコアプロセッサ１０２のＣＰＵのうちｚ＝０のクラスタ＃０のＣＰＵを除く残余のＣＰＵはプロトコルのライブラリやプロセステーブル７００を直接参照できない。ライブラリの場合、ｚ＝０のクラスタ＃０のＣＰまたはメインＣＰＵ１０１がプロトコルのライブラリを複製し、複製したライブラリを各クラスタのＣＰがアクセス可能なローカルメモリへ転送させる。

ｚ＝１のクラスタ＃１のＣＰがＨＴＴＰのライブラリをロードおよびマッピングする場合を例に挙げて説明する。まず、ｚ＝０のクラスタ＃０のＣＰがクロスバーネットワークを介してメモリ１０５へアクセスしてライブラリ群５０２のアプリケーション層のライブラリ群６０３からＨＴＴＰのライブラリを特定し、特定したＨＴＰＰのライブラリを複製する。そして、ｚ＝０のクラスタ＃０のＣＰが、複製したＨＴＴＰのライブラリをローカルメモリ２０１へ転送する。つづいて、ｚ＝１のクラスタ＃１のＣＰがクロスバーネットワーク３０５を介してローカルメモリ２０１にアクセスし、転送されたＨＴＴＰのライブラリをロードおよびマッピングする。

ここで、電源投入直後におけるマルチコアプロセッサの制御処理手順と制御処理手順を示し、つぎに、運用時に利用者からアプリケーションの起動指示を受け付けた場合のマルチコアプロセッサの制御処理手順と制御処理手順を示す。

（電源投入直後におけるメインＣＰＵ１０１による制御処理手順）
図８は、電源投入直後におけるメインＣＰＵ１０１による制御処理手順を示すフローチャートである。まず、メインＣＰＵ１０１が、起動準備が必要なアプリケーションのうち未選択のアプリケーションがあるか否かを判断する（ステップＳ８０１）。電源投入直後に起動準備が必要なアプリケーションとは、上述のようにメーラやダイヤルアップが挙げられる。

起動準備が必要なアプリケーションのうち未選択のアプリケーションがあると判断された場合（ステップＳ８０１：Ｙｅｓ）、未選択のアプリケーションの中から任意のアプリケーションを選択する（ステップＳ８０２）。つぎに、メインＣＰＵ１０１が、選択されたアプリケーションに関するライブラリをリンカによりリンクすることで、実行オブジェクトを特定する（ステップＳ８０３）。

そして、メインＣＰＵ１０１が、プロセステーブルを読み出し（ステップＳ８０４）、実行オブジェクトの階層に対応する階層のクラスタ群から実行オブジェクトを割り当てるクラスタを決定する（ステップＳ８０５）。ここでは、実行オブジェクト（ライブラリ）に記述されているコードの処理が割り当てられることを省略し、実行オブジェクト（ライブラリ）が割り当てられると称している。具体的には、たとえば、メインＣＰＵ１０１が、各クラスタの負荷量を集約して割り当てるクラスタを決定する。

つぎに、メインＣＰＵ１０１が、決定結果をプロセステーブルに登録し（ステップＳ８０６）、ｉ＝４とし（ステップＳ８０７）、第ｉ層の実行オブジェクトの中で未選択の実行オブジェクトがあるか否かを判断する（ステップＳ８０８）。メインＣＰＵ１０１が、第ｉ層の実行オブジェクトの中で未選択の実行オブジェクトがあると判断した場合（ステップＳ８０８：Ｙｅｓ）、未選択の実行オブジェクトの中から任意の実行オブジェクトを選択する（ステップＳ８０９）。そして、メインＣＰＵ１０１が、実行オブジェクトが割り当てられたクラスタのＣＰへ起動準備指示を通知し（ステップＳ８１０）、起動準備完了の通知を受け付けたか否かを判断する（ステップＳ８１１）。

メインＣＰＵ１０１が、起動準備完了の通知を受け付けていないと判断した場合（ステップＳ８１１：Ｎｏ）、ステップＳ８１１へ戻る。一方、メインＣＰＵ１０１が、起動準備完了の通知を受け付けたと判断した場合（ステップＳ８１１：Ｙｅｓ）、ステップＳ８０８へ戻る。また、メインＣＰＵ１０１が、第ｉ層の実行オブジェクトの中で未選択の実行オブジェクトがないと判断した場合（ステップＳ８０８：Ｎｏ）、ｉ＝７であるか否かを判断する（ステップＳ８１２）。そして、ｉ＝７でないと判断した場合（ステップＳ８１２：Ｎｏ）、ｉ＝ｉ＋１とし（ステップＳ８１３）、ステップＳ８０８へ戻る。

一方、メインＣＰＵ１０１が、ｉ＝７であると判断した場合（ステップＳ８１２：Ｙｅｓ）、ステップＳ８０１へ戻る。つぎに、メインＣＰＵ１０１が、起動準備が必要なアプリケーションのうち未選択のアプリケーションがないと判断した場合（ステップＳ８０１：Ｎｏ）、運用を開始し（ステップＳ８１４）、一連の処理を終了する。

図９は、電源投入直後のＣＰによる制御処理手順を示すフローチャートである。まず、実行オブジェクトが割り当てられたクラスタのＣＰ（図９の説明では省略して「ＣＰ」と称する。）が、メインＣＰＵからの実行オブジェクトの起動準備指示を受け付けたか否かを判断する（ステップＳ９０１）。実行オブジェクトの起動準備とは、実行オブジェクト（ライブラリ）にコーディングされている処理（以降、「実行オブジェクトに関する処理」または「ライブラリに関する処理」と称する。）を直ぐに実行可能な状態にすることを指す。なお、本実施の形態においてプロトコルのライブラリに関する処理とプロトコルに関する処理は同一の意味で用いている。

ＣＰが、メインＣＰＵからの実行オブジェクトの起動準備指示を受け付けていないと判断した場合（ステップＳ９０１：Ｎｏ）、ステップＳ９０１へ戻る。一方、ＣＰが、実行オブジェクトの起動準備指示を受け付けたと判断した場合（ステップＳ９０１：Ｙｅｓ）、実行オブジェクトをローカルメモリ上にマッピングし、実行オブジェクトのコンテキスト情報を生成する（ステップＳ９０２）。コンテキスト情報は周知のようにプログラムの内部状態やプログラムがメモリ上のどこに配置されたかを示す。ここでは、実行オブジェクトに関する処理が、該実行オブジェクトを割り当てられたクラスタがアクセス可能なローカルメモリ上にマッピングされ、ローカルメモリ上のどこにマッピングされているかを示す情報がコンテキスト情報として生成される。

そして、ＣＰが、コンテキスト情報をレディキューに登録すると（ステップＳ９０３）、起動準備完了をメインＣＰＵへ通知し（ステップＳ９０４）、一連の処理を終了する。レディキューとは、周知のように実行できる状態のタスクを管理するためのデータ構造である。ＣＰはレディキューに登録されている実行オブジェクトのコンテキスト情報を取り出すことで、実行オブジェクトに関する処理を直ぐに実行することができる。すなわち、電源投入直後に起動準備が必要なアプリケーションは待ち受け状態となっている。

図１０は、起動準備状態である実行オブジェクトの起動指示を受け付けたＣＰによる制御処理手順を示すフローチャートである。まず、起動準備状態である実行オブジェクトが割り当てられているクラスタのＣＰ（図１０の説明では省略して「ＣＰ」と称する。）が、下層から実行オブジェクトの起動指示を受け付けたか否かを判断する（ステップＳ１００１）。実行オブジェクトの起動指示とは、実行オブジェクトに関する処理の起動指示を指している。まず、ＣＰが、下層から実行オブジェクトの起動指示を受け付けていないと判断した場合（ステップＳ１００１：Ｎｏ）、ステップＳ１００１へ戻る。

一方、ＣＰが、下層から実行オブジェクトの起動指示を受け付けたと判断した場合（ステップＳ１００１：Ｙｅｓ）、起動指示を受け付けた実行オブジェクトに関する処理の実効レートを取得する（ステップＳ１００２）。実効レートは帯域であり、ＣＰは「Ｐｉｎｇ」コマンドにより取得することができる。

ＣＰが、実行オブジェクトに関する処理の実行レート［ｂｐｓ（ｂｉｔ ｐｅｒ ｓｅｃｏｎｄ）］とＣＰＵの処理能力［ｂｐｓ］からＣＰＵ数を算出し（ステップＳ１００３）、算出したＣＰＵ数をプロセステーブルへ登録する（ステップＳ１００４）。ここで、プロセステーブルへの登録について説明する。ｚ＝０のクラスタ＃０のＣＰＵとメインＣＰＵ１０１の場合、メモリ１０５へアクセスして直接プロセステーブル７００に登録する。階層型マルチコアプロセッサ１０２のＣＰＵのうちｚ＝０のクラスタ＃０のＣＰＵを除く残余のＣＰＵについては、ｚ＝０のクラスタ＃０のＣＰＵまたはメインＣＰＵ１０１へプロセステーブル７００に算出したＣＰＵ数を登録するように通知する。

そして、ＣＰが、不要ＣＰＵを停止し（ステップＳ１００５）、レディキューから実行オブジェクトのコンテキスト情報を取得し（ステップＳ１００６）、実行オブジェクトに関する処理を実行する（ステップＳ１００７）。ここで、不要ＣＰＵとは、たとえば、クラスタ内の４つのＣＰＵのうち３つのＣＰＵを用いてプロトコルに関する処理を実行する場合、４つのＣＰＵから３つのＣＰＵを除く残余のＣＰＵを指す。そして、ＣＰが、ソケットを確立し（ステップＳ１００８）、一連の処理を終了する。

図１１は、起動準備が必要なアプリケーションの実行オブジェクトが終了する場合のＣＰによる制御処理手順を示すフローチャートである。起動準備が必要なアプリケーションの実行オブジェクトが割り当てられているクラスタのＣＰ（図１１の説明では省略して「ＣＰ」と称する。）が、当該起動準備が必要なアプリケーションの実行オブジェクトが終了したか否かを判断する（ステップＳ１１０１）。まず、ＣＰが、起動準備が必要なアプリケーションの実行オブジェクトが終了していないと判断した場合（ステップＳ１１０１：Ｎｏ）、ステップＳ１１０１へ戻る。

つぎに、ＣＰが、起動準備が必要なアプリケーションの実行オブジェクトが終了したと判断した場合（ステップＳ１１０１：Ｙｅｓ）、終了した実行オブジェクトのコンテキスト情報をレディキューに退避する（ステップＳ１１０２）。そして、ＣＰが、不要ＣＰＵを停止し（ステップＳ１１０３）、プロセステーブルから終了した実行オブジェクトが割り当てられたクラスタのＣＰＵ数をリセットし（ステップＳ１１０４）、一連の処理を終了する。

（具体例１）
ここで、電源投入直後におけるマルチコアプロセッサシステム１００の制御処理の具体例を説明する。

図１２は、具体例１を示す説明図（その１）である。図１２では、電源投入直後におけるメインＣＰＵ１０１による制御処理と、ｚ＝０のクラスタ＃内のＣＰＵ＃０（クラスタ＃内のＣＰ）による制御処理を示している。まず、起動準備が必要なアプリケーションとしてメーラとダイヤルアップなどが挙げられるが、ここでは、メーラの受信処理を例に説明する。

まず、メインＣＰＵ１０１が、リンカによりライブラリ群からメーラの受信処理に必要な実行オブジェクトを特定する。実行オブジェクトとしてＳＳＬのライブラリとＳＮＭＰのライブラリとＩＭＡＰ４のライブラリが特定される。図１２では、ＳＳＬのライブラリを省略してＳＳＬとし、ＳＮＭＰのライブラリを省略してＳＮＭＰとし、ＩＭＡＰ４のライブラリを省略してＩＭＡＰ４としている。

つぎに、メインＣＰＵ１０１がプロセステーブル７００を読み出し、実行オブジェクトを割り当てるクラスタを決定し、決定結果をプロセステーブル７００に登録する。メインＣＰＵ１０１が、たとえば、プロセステーブル７００を参照すると何も割り当てられていないため、実行オブジェクトをどのクラスタに割り当ててもよい。また、実行オブジェクトが割り当てられたクラスタがオフ状態の場合、メインＣＰＵ１０１がそのクラスタをオン状態の低消費電力モードに切り替える。

図１３は、具体例１において決定結果が登録された例を示す説明図である。ＩＭＡＰ４はアプリケーション層のプロトコルであるため、プロセステーブル１３００では、ＩＭＡＰ４のライブラリが「Ａｐｐｌｉｃａｔｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃０に割り当て予定となっている。「ＣＰＵ＝＃」では、プロトコルに関する処理をクラスタ＃０のＣＰＵのうちのいくつのＣＰＵに割り当てるかが決定されていない状態を示している。

ＳＮＭＰはプレゼンテーション層のプロトコルであるため、プロセステーブル１３００では、ＳＮＭＰのライブラリが「Ｐｒｅｓｅｎｔａｔｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃０に割り当て予定となっている。ＳＳＬはセッション層のプロトコルであるため、プロセステーブル１３００では、ＳＳＬのライブラリが「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃０に割り当て予定となっている。

図１２に戻って、つぎに、ＳＳＬに関する処理がｚ＝０のクラスタ＃０に割り当てられたため、ｚ＝０のクラスタ＃０のＣＰ（ｚ＝０のクラスタ＃０のＣＰＵ＃０）にＳＳＬに関する処理の起動準備指示を通知する。そして、ｚ＝０のクラスタ＃０のＣＰが、ＳＳＬに関する処理の起動準備指示を受け付けると、ＳＳＬに関する処理をローカルメモリ２０３（またはローカルメモリ２０２）にマッピングし、コンテキスト情報を生成する。

つぎに、ｚ＝０のクラスタ＃０のＣＰＵ＃０がＳＳＬのコンテキスト情報をレディキュー１２０１に登録し、ＳＳＬに関する処理の起動準備が完了したことをメインＣＰＵ１０１へ通知する。なお、レディキュー１２０１は、たとえば、ローカルメモリ２０１に記憶されている。そして、メインＣＰＵ１０１が、ＳＳＬに関する処理の起動準備完了を受け付けると、ＳＮＭＰに関する処理が割り当てられたｚ＝１のクラスタ＃０のＣＰＵ＃０へ起動準備指示を通知する。さらに、メインＣＰＵ１０１が、ＳＮＭＰに関する処理の起動準備完了を受け付けると、つぎに、ＩＭＡＰ４に関する処理が割り当てられたｚ＝０のクラスタ＃０のＣＰＵ＃０へ起動準備指示を通知する。

図１４は、具体例１を示す説明図（その２）である。図１４では、図１３につづいてＳＳＬの起動指示を受け付けた場合の例を説明する。ｚ＝０のクラスタ＃０のＣＰＵ＃０が、ＳＳＬの起動指示を受け付けると、ＳＳＬに関する処理の実行レートを取得する。ＳＳＬに関する処理の実行レートが６０［ｂｐｓ］であり、各ＣＰＵの処理能力が３０［ｂｐｓ］であるとする。

ｚ＝０のクラスタ＃０のＣＰＵ＃０が、ＳＳＬに関する処理の実行レートを各ＣＰＵの処理能力で割ることによりＳＳＬに関する処理に必要なＣＰＵ数を算出する。よって、ＳＳＬに関する処理に必要なＣＰＵ数は２である。つぎに、ｚ＝０のクラスタ＃０のＣＰＵ＃０が算出したＣＰＵ数をプロセステーブル１５００に登録する。

図１５は、具体例１において算出結果が登録された例を示す説明図である。プロセステーブル１５００では、「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃０に「ＳＳＬ：：ＣＰＵ＝２」が登録されている。

図１４に戻って、つぎに、ｚ＝０のクラスタ＃０のＣＰＵ＃０が、不要ＣＰＵを停止し（オフ状態に切り替える）、ＳＳＬに関する処理が割り当てられたＣＰＵを低消費電力モードから通常モードに切り替える。そして、ｚ＝０のクラスタ＃０のＣＰＵ＃０が、ＳＳＬのコンテキスト情報をレディキュー１２０１から取得してＳＳＬに関する処理を実行し、ソケットを確立する。なお、ＳＳＬのコンテキスト情報はｚ＝０のクラスタ＃０のＣＰＵ＃０により取得されるとともに、レディキュー１２０１から削除される。ｚ＝０のクラスタ＃０のＣＰＵ＃０はＳＳＬに関する処理を実行すると、プレゼンテーション層のＳＮＭＰの起動指示を通知する。

また、ＳＳＬに関する処理の終了時、ｚ＝０のクラスタ＃０のＣＰＵ＃０はＳＳＬのコンテキスト情報をレディキュー１２０１に退避し、不要ＣＰＵを停止する（オフ状態に切り替える）。そして、ｚ＝０のクラスタ＃０のＣＰＵ＃０はプロセステーブル１５００を読み出し、ＳＳＬに割り当てられているＣＰＵ数をリセットする。つぎに、利用者からアプリケーションの起動指示をメインＣＰＵ１０１が受け付けた場合について説明する。

（マルチコアプロセッサシステム１００のメインＣＰＵ１０１による制御処理手順）
図１６は、アプリケーション起動時のメインＣＰＵ１０１による制御処理手順を示すフローチャートである。ここでは、メインＣＰＵ１０１が利用者からのアプリケーションの起動指示を受け付けた場合の制御処理手順について説明する。まず、メインＣＰＵ１０１が、アプリケーションプログラムの起動指示を受け付ける（ステップＳ１６０１）。

つぎに、ステップＳ１６０２〜ステップＳ１６０８までは、それぞれステップＳ８０３〜ステップＳ８０９と同一処理であり、ステップＳ１６１１とステップＳ１６１２は、それぞれステップＳ８１２とステップＳ８１３と同一処理であるため、説明を省略する。ここでは、ステップＳ１６０９およびステップＳ１６１０とステップＳ１６１３〜ステップＳ１６１５について説明する。

まず、メインＣＰＵ１０１が、実行オブジェクトが割り当てられたクラスタのＣＰへ起動指示を通知し（ステップＳ１６０９）、起動完了の通知を受け付けたか否かを判断する（ステップＳ１６１０）。そして、メインＣＰＵ１０１が、起動完了の通知を受け付けていないと判断した場合（ステップＳ１６１０：Ｎｏ）、ステップＳ１６１０へ戻る。一方、起動完了の通知を受け付けたと判断した場合（ステップＳ１６１０：Ｙｅｓ）、ステップＳ１６０７へ戻る。

つぎに、ステップＳ１６１３において、メインＣＰＵ１０１が、アプリケーションのコンテキスト情報を生成し（ステップＳ１６１３）、通信層間のソケットを確立し（ステップＳ１６１４）、アプリケーションソフトウェアを起動し（ステップＳ１６１５）、一連の処理を終了する。

図１７は、起動指示を受け付けたＣＰによる制御処理手順を示すフローチャートである。まず、実行オブジェクトが割り当てられたクラスタのＣＰ（図１７では省略してＣＰと称する。）が、メインＣＰＵから実行オブジェクトの起動指示を受け付けたか否かを判断する（ステップＳ１７０１）。ＣＰが、メインＣＰＵから実行オブジェクトの起動指示を受け付けていないと判断した場合（ステップＳ１７０１：Ｎｏ）、ステップＳ１７０１へ戻る。

一方、ＣＰが、メインＣＰＵから実行オブジェクトの起動指示を受け付けたと判断した場合（ステップＳ１７０１：Ｙｅｓ）、起動指示を受け付けた実行オブジェクトのコンテキスト情報を生成し（ステップＳ１７０２）、コンテキスト情報をレディキューに登録する（ステップＳ１７０３）。つぎに、ステップＳ１７０４〜ステップＳ１７１０までは、それぞれステップＳ１００２〜ステップＳ１００８と同一処理であるため説明を省略する。そして、ステップＳ１７１０のつぎに、実行オブジェクトの起動完了をメインＣＰＵへ通知し（ステップＳ１７１１）、一連の処理を終了する。

図１８は、利用者の起動指示により起動したアプリケーションが終了する場合のＣＰによる制御処理手順を示すフローチャートである。利用者の起動指示により起動したアプリケーションであり、かつ電源投入直後に起動準備が必要でないアプリケーションの実行オブジェクトが割り当てられたクラスタのＣＰ（図１８では省略してＣＰと称する。）が、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了したか否かを判断する（ステップＳ１８０１）。

ＣＰが、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了していないと判断した場合（ステップＳ１８０１：Ｎｏ）、ステップＳ１８０１へ戻る。一方、ＣＰが、利用者の起動指示により起動したアプリケーションの実行オブジェクトが終了したと判断した場合（ステップＳ１８０１：Ｙｅｓ）、終了した実行オブジェクトのコンテキスト情報を削除する（ステップＳ１８０２）。

そして、ＣＰが、不要ＣＰＵを停止し（ステップＳ１８０３）、プロセステーブルから終了した実行オブジェクトに関する記述を削除し（ステップＳ１８０４）、一連の処理を終了する。また、階層型マルチコアプロセッサ１０２のうちｚ＝０のクラスタ＃０のＣＰＵを除く残余のＣＰＵはプロセステーブルへ直接アクセスできないため、プロセステーブルへの登録処理と同様にプロセステーブルからの削除処理についてもメインＣＰＵ１０１かｚ＝０のクラスタ＃０のＣＰＵへ実行オブジェクトに関する記述の削除を通知する。そして、メインＣＰＵ１０１またはｚ＝０のクラスタ＃０のＣＰＵが削除処理を実行する。

（具体例２）
ここで、利用者からのアプリケーションの起動指示を受け付けた場合のマルチコアプロセッサシステムの制御処理の具体例を説明する。

図１９は、具体例２を示す説明図（その１）である。まず、メインＣＰＵ１０１がブラウザの起動指示を受け付け、リンカによりライブラリ群５０２からリンクして実行オブジェクトを特定する。ブラウザの実行オブジェクトとして、アプリケーション層のＨＴＴＰのライブラリおよびＦＴＰのライブラリと、プレゼンテーション層のＨＴＭＬのライブラリと、セッション層のＴＬＳのライブラリとが特定される。

そして、メインＣＰＵ１０１が、プロセステーブル１３００を読み出し、特定した各実行オブジェクトを該実行オブジェクトの階層に対応する階層のクラスタ群からどのクラスタに割り当てるかを決定し、プロセステーブル１３００に登録する。メインＣＰＵ１０１は、各階層のクラスタ群において各クラスタに異なる通信機能を割り当てるように制御する。

ＴＬＳのライブラリが割り当てられるクラスタの決定例を説明する。たとえば、プロセステーブル１３００では、「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」においてクラスタ＃０にＳＳＬのライブラリが割り当てられ、クラスタ＃１〜クラスタ＃３には何も割り当てられていないことを示している。メインＣＰＵ１０１は、プロセステーブル１３００を参照し、ｚ＝０のクラスタ群のうちＳＳＬのライブラリが割り当てられているクラスタ＃０を除く残余のクラスタからＴＬＳのライブラリを割り当てるクラスタを決定する。ここでは、メインＣＰＵ１０１が、ＴＬＳのライブラリをクラスタ＃１に割り当てると決定する。また、もし「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃０〜クラスタ＃３のすべてに割り当てられていることがプロセステーブル１３００で示されている場合、たとえば、「ＣＰＵ＝」を参照してＣＰＵが空いているクラスタを実行オブジェクトの割り当てクラスタに決定することとする。

図２０は、具体例２において決定結果が登録された例を示す説明図である。プロセステーブル２０００が、決定結果が登録された例である。ＴＬＳはセッション層のプロトコルであるため、プロセステーブル２０００の「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」においてＴＬＳがクラスタ＃１に割り当てられていることが示されている。ＨＴＭＬはプレゼンテーション層のプロトコルであるため、プロセステーブル２０００の「Ｐｒｅｓｅｎｔａｉｏｎ＿Ｌａｙｅｒ：」においてＨＴＭＬがクラスタ＃１に割り当てられていることが示されている。ＨＴＴＰおよびＦＴＰはアプリケーション層のプロコルであるため、プロセステーブル２０００の「Ａｐｐｌｉｃａｔｉｏｎ＿Ｌａｙｅｒ：」においてＨＴＴＰがクラスタ＃１に割り当てられていることが示され、ＦＴＰがクラスタ＃２に割り当てられていることが示されている。

図１９に戻って、メインＣＰＵ１０１が、プロセステーブル２０００に決定結果を登録後、起動指示をそれぞれのプロトコルに関する処理が割り当てられたクラスタのＣＰへ通知する。ここで、メインＣＰＵ１０１は、下層のプロトコルに関する処理が割り当てられたクラスタのＣＰから順に上層のプロトコルに関する処理が割り当てられたクラスタのＣＰへ通知する。具体例２においては、まず、ＴＬＳに関する処理が割り当てられたｚ＝０のクラスタ＃１のＣＰへＴＬＳに関する処理の起動指示を通知し、つぎに、ＨＴＭＬに関する処理が割り当てられたｚ＝１のクラスタ＃１のＣＰへＨＴＭＬに関する処理の起動指示を通知する。そして、ＨＴＴＰに関する処理が割り当てられたｚ＝２のクラスタ＃１のＣＰへＨＴＴＰに関する処理の起動指示を通知し、ＦＴＰに関する処理が割り当てられたｚ＝２のクラスタ＃２のＣＰへＦＴＰに関する処理の起動指示を通知する。

図２１は、具体例２を示す説明図（その２）である。ＴＬＳに関する処理は、ｚ＝０のクラスタ＃１に割り当てられた。まず、ｚ＝０のクラスタ＃１のＣＰが、ＣＰＵからの起動指示を受け付けると、ＴＬＳに関する処理をローカルメモリ上にマッピングしてコンテキスト情報を生成し、生成したＴＬＳのコンテキスト情報をレディキュー２１０１に登録する。

つぎに、ｚ＝０のクラスタ＃１のＣＰが、実行レートを取得し、取得した実行レートとクラスタ＃１内のＣＰＵの処理能力とに基づいてＴＬＳに関する処理に必要なＣＰＵ数を算出する。ここで、取得した実行レートが１２０［ｂｐｓ］であり、階層型マルチコアプロセッサ１０２の各ＣＰＵの処理能力が３０［ｂｐｓ］であると、ＴＬＳに関する処理に必要なＣＰＵ数は４つである。つぎに、ｚ＝０のクラスタ＃１のＣＰが、プロセステーブル２０００へ算出したＣＵＰ数（算出結果）を登録する。

図２２は、具体例２において算出結果が登録された例を示す説明図である。プロセステーブル２２００は、算出結果が登録された例である。プロセステーブル２２００の「Ｓｅｓｓｉｏｎ＿Ｌａｙｅｒ：」のクラスタ＃１の行には、「ＴＬＳ：：ＣＰＵ＝４」と記述され、クラスタ＃１の４つのＣＰＵにＴＬＳが割り当てられて並列に処理されることが示されている。

図２１に戻って、ｚ＝０のクラスタ＃１のＣＰが、レディキュー２１０１からＴＬＳのコンテキスト情報を取得してＴＬＳに関する処理を実行し、ＴＬＳのソケットを確立する。そして、ｚ＝０のクラスタ＃１のＣＰがメインＣＰＵ１０１へＴＬＳに関する処理の起動完了を通知し、メインＣＰＵ１０１がｚ＝０のクラスタ＃１のＣＰからのＴＬＳに関する処理の起動完了を受け付けると、ｚ＝１のクラスタ＃１のＣＰへＨＴＭＬに関する処理の起動指示を通知する。

また、具体例２で挙げたブラウザが終了する場合、ブラウザの実行オブジェクトが割り当てられたクラスタのＣＰが、該実行オブジェクトのコンテキスト情報を削除する。そして、プロセステーブル２２００から終了した実行オブジェクトに関する記述を削除する。削除結果は、プロセステーブル１３００と同一となる。

以上説明したように、階層型マルチコアプロセッサによれば、一連の通信機能を構成する階層群の階層ごとにＣＰＵ群を有している。そして、階層群のうち一の階層のＣＰＵ群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のＣＰＵ群に接続されることにより、ＣＰＵ間の接続を減少させることができ、システムの大規模化を防止することができる。

また、各階層のコア群が複数のクラスタに分割されていることで、一の通信機能に関する処理を一のクラスタのコア群に実行させることができる。

また、各クラスタが複数のコアを有することで、一つの通信機能を並列に実行させることができ、スループットを向上させることができる。

以上説明したように、マルチコアプロセッサシステムおよび制御プログラムによれば、通信プロトコルの階層ごとにＣＰＵ群を有することで、一の通信機能に関する処理を一の通信機能の階層に応じた階層のＣＰＵ群に割り当てる。これにより、通信プロトコルを伴うアプリケーションソフトウェアの処理を効率的に実行することができる。

また、各階層のコア群が複数のクラスタに分割されている場合、同一階層の通信プロトコルに関する処理が同時に実行されても異なるＣＰＵに割り当てることで各処理を効率的に実行することができる。

また、各クラスタが複数のＣＰＵを有している場合、各クラスタに割り当てられた通信機能に関する処理を各クラスタ内の複数のコアに並列実行させることで、スループットを向上させることができる。

１００ マルチコアプロセッサシステム
１０２ 階層型マルチコアプロセッサ

Claims (7)

1. 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、
   前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されることを特徴とする階層型マルチコアプロセッサ。
2. 前記各階層のコア群は、複数のクラスタに分割されていることを特徴とする請求項１に記載の階層型マルチコアプロセッサ。
3. 前記各クラスタは、複数のコアを有することを特徴とする請求項２に記載の階層型マルチコアプロセッサ。
4. 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されている階層型マルチコアプロセッサと、
   前記各階層のコア群に、当該階層に応じた通信機能を割り当てるように制御する制御手段と、
   を備えることを特徴とするマルチコアプロセッサシステム。
5. 前記階層型マルチコアプロセッサでは、前記各階層のコア群が複数のクラスタに分割されており、
   前記制御手段では、前記各階層のコア群において分割された前記各クラスタに異なる通信機能を割り当てるように制御することを特徴とする請求項４に記載のマルチコアプロセッサシステム。
6. 前記階層型マルチコアプロセッサでは、前記各クラスタが複数のコアを有しており、
   前記制御手段では、前記各クラスタに割り当てられた通信機能に関する処理を、前記各クラスタ内の複数のコアに並列実行させることを特徴とする請求項５に記載のマルチコアプロセッサシステム。
7. 通信プロトコルに従って分割された一連の通信機能を構成する階層群の階層ごとにコア群を有し、前記階層群のうち一の階層のコア群が、当該一の階層の通信機能に続いて実行される通信機能を構成する他の階層のコア群に接続されている階層型マルチコアプロセッサを制御するコアに、
   前記各階層のコア群に、当該階層に応じた通信機能を割り当てるように制御する制御工程、
   を実行させることを特徴とする制御プログラム。

Images