スライド 1

マルチコア メニーコア向けの OS 2010 年 3 月 7 日 NGCOM 第 7 回ワークショップ東京農工大学佐藤未来子 Mail: mikiko@namikilab.tuat.ac.jp URL: www.namikilab.tuat.ac.jp/~mikiko/

目次 背景 研究課題 目標 方針 システムの全体構成 研究成果 (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 まとめ 2

背景 マルチコア / メニーコアプロセッサの時代到来 2004 年頃 :Intel Xeon や IBM Power4/5 といったマルチスレッディング, マルチコアがサーバや PC で採用 Windows や Linux などの汎用 OS が粗粒度命令流を並列実行 2006 年頃 :RP-1(Renesas/ 日立 / 早稲田 ),Cell/B.E. など, マルチコアプロセッサを身近で活用可能に! RP-1 や Cell/B.E. に独自 OS や既存 OS を移植 マルチコアを自由に使い倒して, 細粒度の科学技術計算や中粒度のマルチメディア系計算などを 1 チップで処理する基盤作り 野尻他, マイクロカーネル方式による Cell/B.E. 向け OS 構成法の提案と MINIX 3 による実現, 情処 OS 研, Vol.2009-OS-110, pp.91-98 (2009.01) 太田他,Cell/B.E. の SPE 向け軽量カーネルの設計と試作, 情処 OS 研, Vol.2009-OS-111, No.37, pp.1-8 (2009.04) 3

背景 2007 年以降 :RP-2(Renesas/ 日立 / 早稲田 ) など 8 コアも身近に 従来の SMP を前提とした OS アーキテクチャではうまく使いこなせないということを痛感 コア 0 CM Snoop Controller コア 1 CM コア 2 CM 外部メモリ コア 3 CM RP-1 のアーキテクチャ ( 共有メモリ型の 1 クラスタ構成 ) CM:Cache Memory コア 0 CM コア 4 CM Snoop Controller コア 1 CM コア 5 CM コア 2 CM コア 6 CM Snoop Controller コア 3 CM コア 7 CM RP-2 のアーキテクチャ ( 共有メモリ型の 2 クラスタ構成 ) 外部メモリ 4

背景 2010/2/26 低消費電力メニーコアプロセッサ技術シンポジウム at 早稲田大学 早稲田大学の NEDO, 富士通, ルネサス,NEC, 東芝の各研究開発の取り組みを発表 プロセス技術の進歩により本当に 1000 コアの時代が来ることをあらためて痛感 コア数が増えるとバス接続では通信ネックになる 各社様々な相互結合網を検討 (NoC:Network-on-Chip) 表 :5mm 2 に ARM コアだけを敷き詰める場合を想定したコア数 プロセス (nm) 90 65 32 ARM7TDMI-S 125 コア 240 コア 989 コア ARM926EJ-S +Cache 16 コア 31 コア 128 コア ( 注 ) 低消費電力メニーコアプロセッサシステム技術シンポジウム資料 P.52 より抜粋 5

背景 ( まとめ ) マルチコア / メニーコアプロセッサ時代を見据えて プログラムの開発環境や実行基盤の研究開発が重要である. シングルコアの時代 周波数向上にともなう性能向上 マルチコア / メニーコア アーキテクチャに適した使い方次第で性能向上 コアや機能が沢山あっても, 適材適所で使いこなすことができなければ, 宝の持ち腐れとなり, 無駄に電力を消費するだけ マルチコアアーキテクチャを活かせるような プログラム実行基盤の研究 2007 年以降,RP-1 を活用して研究を開始 6

既存の基盤ソフトウェアと研究課題 マルチコアプロセッサ活用のために着目すべき技術 省電力機能, 多コア化, 多機能化などに応じた最適なリソース管理, スケジューリング制御 既存の {SMP 向け 組込み }OS では, - 高コスト ( オーバヘッド ) な実行基盤 軽量なスレッド管理 制御を実現したい - コンパイラからのスケジューリング情報を渡せない コンパイラの静的情報を活かせる環境にしたい - RP-1 のアーキテクチャを活かせない マルチコア オンチップ RAM データ転送 省電力制御など のプロセッサアーキテクチャを活用できるようにしたい 7

目標と方針 マルチコアプロセッサ上で並列プログラムを効率よく制御するプログラム実行基盤の開発 (1) 軽量なスレッド管理 制御ができる独自 OS により並列演算性能を追求 (2)POSIX read ベースのプログラミングモデル Future & MULi (3) 利便性追求のための 2 種 ( 以上 ) の OS を活用するハイブリッド OS でのプログラム実行基盤 VM による複数 OS 稼動方式ではない Future/MULi: マルチコアを活かす軽量な実行基盤 SH-Linux: 入出力管理 プログラム起動制御 1 つのプログラムを複数の OS で処理する 8

システムの全体構成 RP-1 を用いたマルチコア向けプログラム実行基盤を研究開発中 Future 用アプリケーションプログラム MULi 他システム ネットワーク Linux I/O 代行処理 OS 連携機構 プロセス管理 Future メモリ管理 スレッド制御 GUI ファイル CPU#0 CPU#1 CPU#2 CPU#3 main memory SH-4A マルチコア (4 コア ) I/O 処理 並列演算処理 SH マルチコアプロセッサ RP-1 におけるソフトウェアアーキテクチャ 9

研究成果 (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 10

(1) 軽量なマルチスレッドプログラ ムの実行基盤 スレッドライブラリ MULi ( マリス ) (Userlevel read Library for Multithreaded architecture) POSIX スレッドを管理するスレッドライブラリ ユーザレベルでスレッド制御 - コアへのスレッド割当て, スレッドコンテキスト管理 ライトウェイト OS Future MULi のスレッド制御を支援する OS マルチコアプロセッサの複数コアを仮想化するプロセス管理 例外 コア間割込み等の特権処理 11

Futureのプロセス管理とMULiのスレッド管理 プロセス スレッド管理 MULi ユーザレベルで実コアを仮想化した軽量スレッドを提供 UserLevel スレッド制御 カーネルはコア全体とアドレス空間を仮想化 Future プロセス #1 プロセス #2 プロセス #3 C#3 F#0 F#1 C#0 C#1 C#2 プロセス管理 KernelLevel Core#0 Core#1 Core#2 Core#3 他実行系 他実行系 RP1 Hardware Level 12

Future のプロセス管理の概念 マルチコアプロセッサの複数コアを仮想化する プロセス #0 プロセス #1 プロセス #2 MULi スレッド管理 MULi スレッド管理 MULi スレッド管理 Future プロセス管理 n 個のコアをプロセスへ割当てる Core#0 Core#1 Core#2 Core#3 RP1 13

メニーコア向けプロセス管理 ( 今後 の課題 ) 多コア化への対応として, プロセス起動時に使用コア数を申請. コアがあればプロセス開始, なければ待つ. アドレス空間はFuture が仮想化 どこのコアが割当てられても動けるようにプロセスを管理する必要あり プロセス #3 プロセス #1 プロセス #2 Snoop Controller コア0 CM コア1 CM コア2 CM コア3 CM コア4 CM コア5 CM コア6 CM コア7 CM 外部メモリ Snoop Controller 14

MULi でサポートした Pread I/F スレッド管理系 pthread_create,pthread_join,pthread_exit, pthread_attr_init, pthread_attr_setdetachstate,pthread_attr_getdetachstate, pthread_attr_setbind,pthread_attr_getbind,pthread_yield ( コアへスレッドをバインドする I/F) 同期系 pthread_mutex_lock,pthread_mutex_unlock, pthread_mutex_init,pthread_cond_wait,pthread_cond_signal, pthread_cond_broadcast,pthread_cond_init ローカルメモリ系 pthread_key_create,pthread_key_delete,pthread_getspecific, pthread_setspecific 15

RP-1 での MULi の基本性能 RP-1 プロセッサ ( 早稲田大学, ルネサス, 日立 ) SH-4A (600MHz) 4 core (μsec) 25.00 20.00 15.00 create/join 173 倍 666.8 (μsec) 0.400 0.300 mutex_lock/unlock 0.238 1.6 倍 0.385 10.00 5.00 3.38 3.84 0.200 0.100 0.113 0.00 0.000 MULi (1Core) /SH-C MULi (4Core) /SH-C SH-Linux (1Core) /GCC スレッド生成 終了オーバヘッド MULi (1Core) /SH-C MULi (4Core) /SH-C SH-Linux (1Core) /GCC ロック獲得 解放オーバヘッド pthread_create/join を多用するプログラムの実行が可能 軽量なスレッド実行基盤 OSCAR コンパイラとの親和性が高い 16

研究成果 (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 17

(2)OS による MMU を用いたスクラッ チパッドメモリの管理方式 スクラッチパッドメモリ (SPM) 低消費電力 ( ) キャッシュメモリと同等のアクセス性能 ( ) 主記憶 SPM 間のデータ転送はソフトウェア制御 ( ) 適切な割当て管理をすれば有効なメモリ資源 RP-1 の各コアにオンチップ RAM(SPM) がある 128KB/ コア ローカルアクセス :1cycle バス経由アクセス :5cycle~(case by case) バス経由で他コア上のオンチップ RAM にもアクセス可能 MMU アドレス変換対象 18

従来の SPM 管理方式 静的に SPM を割り当てる方式 コンパイラやプログラマがアクセス頻度の高いコードやデータ領域を明示的に SPM へ配置 < 利点 > 性能や省電力面で非常に効果あり < 問題点 > プログラム実行環境が限定的 - SPM の容量や物理アドレスに依存したコード - あらかじめ実行するタスクやタスク数を限定 - I/O 処理やマルチプロセス下における OS による動的な挙動は想定外 システムソフトウェアによる動的な SPM 管理 19

本研究の目標と方針 Future のページ管理に,SPM 管理の枠組みをマルチコア向けに導入 (1) マルチプロセス マルチコアという擾乱の多い環境でも SPM を活用できるようにする. MMU 例外を契機とした SPM 割当て Code,Data,Stack,Heap どの領域にも適用可能 コンパイラヒントや OS が得る情報などを基にした SPM 割当て 実行するコードはメモリアーキテクチャに依存しない. (2) 各コアの SPM を共有メモリとして活用する. 従来のメモリアーキテクチャ SPM は各コア固有のメモリ資源 本研究でのアプローチ 全コアの SPM を共有メモリとして仮想化した新たな記憶階層 20

メモリ管理の概要 SH-4A の MMU を活用し, 頻繁にアクセスする仮想アドレスに対して,OS がページ単位で SPM を動的に割り当てる. プロセスプロセスプロセス dat dat dat Future プロセス管理 メモリ管理 コア0 MMU コア1 MMU コアn MMU SPM#0 SPM#1 SPM#n main memory 21

本研究のメモリ階層 SPM という新たな記憶階層を追加 ここのページ IN/OUT は OS の仕事 4KB ページ 仮想アドレス空間 SPM#n SPM#1 SPM#0 PageB Cache PageA 主記憶 MMU (TLB) PageB PageA ハードウェアによるデータ転送 仮想アドレスの流れ OS によるデータ転送 物理アドレスの流れ 22

メモリ管理の概要 OS のメモリアロケーションの主な流れ 1MMU のページフォルト例外を契機とする 2 ページ単位で主記憶あるいは SPM を割り当てる どちらのメモリ資源を割当てるかは SPM アロケーション戦略で決める SPM を割当てる際には, 自コアの SPM を割当てる 他コアの SPM は参照のみ 3SPM が不足した場合, 主記憶へページアウトして,SPM ページを確保する SPM への割り当てをあきらめ, 主記憶を割当てる 23

マルチコアにおける SPM 共有 Core#0 Core#1 Core#n CPU#0 CPU#1 CPU#n Cache Cache Cache SPM#0 PageA SPM#1 SPM#n 他コアの SPM 上にページが割当てられていれば参照 各コアの見かけ上の SPM サイズが増大 ( ) ただし, 外部バス経由で SPM を参照する必要あり ( ) キャッシュメモリを併用してアクセス性能をカバー 24

実装 RP-1 プロセッサ ( 早稲田大学, ルネサス, 日立 ) SH-4A (600MHz) 4 core SPM :128KB 4 core MMU: ソフトウェア TLB ハンドリング TLB ミス例外が発生時に動的な情報を収集 OS:Future 2 層構造ページテーブル SPM ページフレームの管理 各コアごとに SPM ページフレームの割り当て状況を管理 SPM のアロケーション戦略 SPM 割り当て対象 スタック, ヒープ, データ アクセス頻度の高いセクションをあらかじめ OS へ指定 SPM 割当て抑制機能 空きがなくなり次第割当てを抑制 25

評価 使用したベンチマークプログラム Radix ( 基数ソート ) FFT ( 高速フーリエ変換 ) 1 プロセス 4 スレッド実行 SPM 容量よりも多いデータを扱うようにパラメータを設定 実行性能と消費電力を計測 プログラムの核の部分で測定 ( 初期化処理と終了処理を除く ) SPM を活用しない場合に対する,OS で SPM を管理した場合の比率を算出 ( 同一バイナリで実測 ) コンパイラの静的解析によるヒントや特別な動的情報を得ないでどの程度の性能改善が図れるか? 26

実行性能の比率 120.0% 100.0% Radix 同等約 50% の改善 80.0% 60.0% 40.0% 20.0% 0.0% 27 16,384 (1056KB) 32,768 (1184KB) 65,536 (1440KB) 131,072 (1952KB) Execution Ratio 262,144 (2976KB) Sort Key Numbers 120.0% 100.0% 80.0% 60.0% 40.0% 20.0% 0.0% FFT 約 30% の改善 4,096 (168KB) 16,384 (552KB) 65,536 (2092KB) Complex Doubles 同等 Execution Ratio

消費エネルギーの比率 120.0% 100.0% Radix 約 30% の改善 120.0% FFT 同等同等約 22% の改善 100.0% 80.0% 60.0% 40.0% 80.0% 60.0% 40.0% 20.0% 0.0% 16,384 32,768 65,536 131,072 262,144 Energy ratio 20.0% Sort Key Numbers 0.0% (1056KB) (1184KB) (1440KB) (1952KB) (2976KB) 4,096 (168KB) 16,384 (552KB) 65,536 (2092KB) Energy ratio Complex Doubles 28

考察とまとめ マルチコア環境での評価 特別なメモリアロケーション戦略なしに, 性能比率を Radix で約 50%,FFT で約 30% 改善できた. SPM 管理による処理オーバヘッドは増加したが,SPM 活用による性能改善あり. データサイズが大きい場合は,SPM を活用しない場合と同等の値を示した. SPM を使い切ったものの性能向上には至らなかった. ( 最適な SPM 割り当てが行えなかった ) 現状では OS がページ単位で SPM を動的に割当てる枠組みを試作したのみ SPMに対するメモリアロケーション戦略を最適化することで, 性能向上 消費エネルギー削減の余地がある 29

研究成果 (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 30

(3) 汎用 OS とマルチコアに特化し た専用 OS を連携動作させる機構 研究の動機 Future/MULi によりマルチスレッドプログラムを軽量に管理 制御することはできた しかし, 従来の汎用 OS の API などの利便性が不足 並列演算向け専用 OS と汎用 OS を連携させるハイブリッド OS 構成 2 つの OS を適材適所に利用し 利便性と演算性能を両立 31

ハイブリッド OS の概念 マルチコアプロセッサ上で複数の OS を並列実行 VM は使わず, ハードウェアをマスターとなる汎用 OS が管理 汎用 OS から Future を起動する仕組み Future に備えていない GUI, ネットワーク, ファイル I/O の処理を, 汎用 OS 側で補う Future 用アプリケーションプログラム MULi 他システム ネットワーク Linux I/O 代行処理 OS 連携機構 プロセス管理 Future メモリ管理 スレッド制御 CPU#0 CPU#1 CPU#2 CPU#3 GUI ファイル main memory SH-4A マルチコア (4 コア ) I/O 処理 並列演算処理 32

33 OS 連携機構で提供する機能 複数 OS の同時実行 Linux 側がマスターとなり,Future のカーネルをロードし ブートする Linux からの Future プロセスの実行 Linux ファイルシステム上で管理している Future 用プログラムを Linux からロードし Future 上で実行 Future 用プログラム起動時に CPU コア数を指定 ファイル入出力の代行 Future 用プログラムの I/O 系システムコールを Linux へフォワードし,Linux で代行 Linux で管理している I/O を利用可能 Future プログラムから open/close/read/write が可能 33

OS 連携機構の仕組み ( 概念図 ) デバイスドライバを介した OS 間通信で OS を連携 Future 側プロセスと 1 対 1 で対応する Linux 側プロセスが Future プログラムの起動制御や ファイル入出力の代行処理などを行う Linux 側プロセス #2 Linux 側プロセス #1 Future プログラム制御 システムコール代行処理 1 対 1 対応 Future 側プロセス #2 Future 側プロセス #1 MULi スレッド管理 User Level Linux Future プロセス管理 デバイスドライバ OS 間通信 Future システムコール 例外 割込み処理 スレッド制御 Kernel Level CPU#0 CPU#1 CPU#2 CPU#3 Hardware Level 34

35 Linux 側のデバイスドライバの設計 デバイスドライバに対するシステムコールおよび OS 間通信のメッセージによってFutureと連携 read/write Linux 通信バッファ Future とのメッセージ送受信 mmap ioctl Future の起動 プロセスの生成などの操作 Future 用メモリ領域へのアクセス Future Future 用メモリ領域 ハンドラ名 read write mmap ioctl(boot_future) ioctl(create_proc) ioctl(run_proc) 機能 FutureからOS 間通信のメッセージを受信 FutureへOS 間通信のメッセージを送信 Future 用領域をLinuxプロセスのアドレス空間にマップ CPU#1のリセットベクタを指定し,CPU#1を起動させる Futureのプロセス情報の生成 35 Futureプロセスの実行依頼を送信する

36 OS 連携機構のまとめ OS 連携機構のための各機能を実現 Linux から Future の起動,Future 用プログラムの起動を可能にした 今回は Future を連携させたが,OS 連携の I/F を使えば, 他 OS と Linux との連携も実現可能である Challenge してみたい! Future 用プログラムからのファイル I/O が利用可能 read で約 43%,write で約 10% の速度低下がみられたが, 画像処理, 計算処理等の入出力データを汎用 OS 上で管理できることは有用である 意外と便利! 36

研究成果 (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 37

(4) 汎用 OS から動的再構成可能プ ロセッサを制御する機構 38 近年, 動的再構成可能プロセッサを搭載したマルチコアも登場 RP-X には 4 つの動的再構成可能プロセッサ (FE-GA) が搭載されている 演算内容に合わせてハードウェアを再構成して高い性能を得られる OS による仮想化があまり行われておらず, 直接プログラムから制御することが多い 汎用 OS から動的再構成可能プロセッサを制御する機構を提供しよう! 38

動的再構成可能プロセッサ制御 機構の設計概要 動的再構成可能プロセッサに対する基本操作 制御レジスタを変更する操作 データを配置するローカルメモリへの入出力データの転送 これらをデバイスドライバと, それをラップするライブラリ経由で操作 39 システムコール I/F Linux ユーザプロセス ライブラリ API User Level read/write デバイスドライバ Linux ioctl Kernel Level ローカルメモリ レジスタ 動的再構成可能プロセッサ Hardware Level 39

動的再構成可能プロセッサ制御 機構の設計 (1) Linux デバイスドライバの設計 ローカルメモリ (CRAM) 入出力, 制御レジスタの操作, 同期制御のためのインターフェースをシステムコールとして提供 40 表 : 制御ドライバの主なインターフェース ハンドラ名 機能 read/write CRAMへの入出力を行う lseek CRAMの入出力位置を指定 ioctl(get_reg) 指定した制御レジスタの値を取得 ioctl(set_reg) 指定した制御レジスタの値を設定 poll FE-GAの同期制御を行う 40

動的再構成可能プロセッサ制御 機構の設計 (2) 制御ライブラリの設計 ユーザプロセスに対して前述のデバイスドライバのシステムコールをラップしたライブラリを提供 41 表 :FE-GA 制御ライブラリの API の例 関数名 機能 fega_open FE-GAの制御ドライバをオープン fega_setconfig コンフィグレーションデータをロード fega_start FE-GAによる演算を開始 fega_stop FE-GAの動作を停止 cram_seek CRAMの読み書き位置を設定 41

42 コード記述の例 従来手法のコード // コンフィグレーションは予め開発ツールで転送 //cram への書込み for(i=0; i<size; i++){ *(volatile unsigned short *) 0xfec00000 + (0x2*i) = data[i]; } //FE-GAの起動 *(volatile unsigned long *) 0xfec30008 = 1; *(volatile unsigned long *) 0xfec30000 = (0x80710000 1); //cram からの読込み for(i=0; i<size; i++){ result[i] = *(volatile unsigned short *) 0xfec04000 + (0x2*i); } 本システムを利用したコード // ドライバのオープン fd = fega_open (); // コンフィグレーションの設定 set_config(fd,./config_data ); //cramへの書込み cram_seek(fd,0,0); write(fd, data, size); //FE-GA の起動 fega_start(fd); //cram からの読込 cram_seek(fd, 1, 0); read(fd, result, size); // ドライバのクローズ fega_close(fd); //arg1:cram 番号,arg2:offset 42

動的再構成可能プロセッサ制御 機構のまとめ Linux と連携して動的再構成可能プロセッサを利用可能とした Linux のファイルシステムや I/O を利用可能 コンフィグレーションやデータをファイルシステムで管理できるので便利! 他の Linux プロセスとの同時実行も可能 なお,OS 連携機構および動的再構成可能プロセッサ制御機構については, 情報処理学会第 72 回全国大会 3L-5 マルチコア CPU における OS の資源管理方式の研究 で発表します. 43 43

全体のまとめ マルチコアプロセッサにおけるプログラム実行基盤の研究について発表した. (1) 軽量なマルチスレッドプログラムの実行基盤 (2)OS による MMU を用いたスクラッチパッドメモリの管理方式 (3) 汎用 OS とマルチコアに特化した専用 OS を連携動作させる機構 (4) 汎用 OS から動的再構成可能プロセッサを制御する機構 学生の研究であるため, 卒業と同時に止まってしまう研究もある もったいない 世代交代をスムーズに行い, 残された研究課題を追 究したい! 44

全体のまとめ やっとプログラム実行基盤の基礎が整ったところ 残された課題は多い - スレッドスケジューラ -SPM メモリアロケーション -8 コア 16 コア対応のプロセス管理 - コンパイラとの連携 - Linux,Future 意外の OS を対象とした OS 連携機構 - 動的再構成可能プロセッサ制御におけるデータ転送制御などを追究すると楽しそう 45

(END) 46