ハードウェアスケジューラによるLinux上での近細粒度並列処理の高速化

全文

(1)社団法人情報処理学会研究報告. 2006-ＡＲＣ－１７０（５）. 2006／11／2８. IPSJSIGTbchnicalReport. ハードウエアスケジューラによるLinux上での近細粒度並列処理の高速化大原_輝↑ 大野和彦↑. 佐々木敬泰↑. 近藤利夫↑. 近年，ＳＭＴやＣＭＰプロセッサが高性能計算機だけでなく，一般的なパソコンや組込み用途まで. 幅広く利用されるようになりつつあり，今後は１つのコンピューターシステムに多数のプロセッサコアが搭載されるようになると考えられる．そのような状況において，ソフトウェア開発の現場においては，あらかじめプロセッサコア数が与えられなくても多数のコアを有効活用できることが強く求められている．我々はそのような状況に際し，近細粒度並列処理が有効と考える．一方で，近年，高性能計算機による科学技術計算から組込み用途まで幅広く利用できるＯＳとして，Linuxが普及し始めている．しかしながら，Linuxは近細粒度処理を前提として設計されていないため，通常のLinux上でタスク切り替えが頻繁に発生する近細粒度並列処理を適用すると，スケジューリングを含むコンテキストスイッチのオーバーヘッドが問題となる．そこで，本稿では著者らの提案しているハードウェアスケジューラSSH(SchedulingSupportHardware)をLinuxに適用することで上記問題を解決. することを目指す．. AccelerationfbrfinegrainedparallelprocessingonLinuxwithhardwaresclleduler KAzuKIOHARA,tnkKAHIRoSAsAKI,↑ＫＡｚｕＨＩＫｏＯＨＮｏｔａｎｄＴｏｓＨＩｏＫｏＮＤｏＴ. Recentyears,ＳＭＴｏｒＣＭＰｐｒｏｃｅｓｓｏｒｓａｒｅｕｓｅｄｎｏｔｏｎlyhighperfbrmancecomputingbut alsogeneralpersonalcomputerorembeddedcomputer・InthenearfUture，onecomputer systemwillhavemanyprocessorcores、Inthissituation，itisrequiredfbrsoftwaredevelop 、enttoutiUzemanycoreseflicientlｙｂ園cingthissituation,wethinkthefinegrainedparallel processingispromising、Ｏｎｔｈｅｏｔｈｅｒｓｉｄｅ,LinuxisusedasgeneralOSfbrfromhighperfbr邑. mancecomputingtoembeddedsystems、Butifweadoptthefinegrainedparallelismintothe. genera1Linuxsystemsjtheconteg[tswitchoverheadincludingschedulingoverheadbecomes. aseriousproblem、so,inordertoⅡeducetheoverhead,weintroducetheSSH(Scheduling SupportHardware)weproposedintoLinuxsystem．. 末，各種制御装置などの組込用途でも同様である．. １．はじめに. 近年，ＳＭＴやＣＭＰプロセッサ等の普及が始まり，１つのコンピューターシステムに複数のプロセッサコ. アが搭載され，その数はシステムにより異なるという状況になりつつある．今後はローエンドとハイエンドのシステムが搭載するプロセッサコアの数はさらに大きく異なってくるものと考えられる．そのような状況においてはソフトウェアの開発時点でシステムに搭載されているプロセッサコア数が与えられていなくても多数のコアを有効活用できることが求められる．この. ような状況は，高性能計算機やパソコンだけでなく，高性能化，高機能化の進むデジタル家電やモバイル端. この様な状況に際し，我々は近細粒度並列処理が有効であると考えている．近細粒度並列処理では数百から数千サイクルで完了するスレッドをプロセッサ数よりも圧倒的に多く生成する．そして，これらを実況条件の整ったものからプロセッサに割り当て，アイドル状態になるプロセッサを発生させないようにする．一方，高性能計算機による科学技術計算から組込み用途まで幅広く利用できるＯＳとしてLinuxが着目されている．しかしながら，この細粒度並列処理を Linux上で用いる場合，スレッドの生成，スケジューリング）コンテキストスイッチが多発し，これらによるオーバーヘッドが大きくなる．そこで，本研究では著者らが提案しているハードウェアスケジューラであ. るSSH(SchedulingSupportHardwaJ,e)')'2)を利用. ↑三重大学大学院工学研究科補報工学専攻. GraduateSchoolofEngineering,ＭｉｅUniversity. し，ユーザープログラムの実行と並行してハードウェ. －２５－.

(2) アでスケジューリング処理を行い，スケジューリング. 慨。||shaz．。､｡エ. 時間を隠蔽する．本稿では予備評価としてLinuxのス. Bｕｓ. ケジューラの性能評価とＳＳＨの利用による性能向上の見積もりを行ったので報告する．. ２．関連研究且迪包. マルチプロセッサ用のタスク・スケジューリング方. ＳＥＥ巴ｍｕｎＩ②ｚＢｕＳハｚｂｉＥｅｚ. 式に関する研究3)~5),7),8）は広く行われているが，そ. 図ユマルチプロセッサアーキテクチャ. の多くはＯＳやマルチスレッド・ライブラリ等，ソフトウェアでタスクのスケジューリングを行うものであ. ３．１ＳＳＨを利用したマルチプロセッサアーキテク. る．また，タスクスケジューリング；あるいはＯＳ全. チャ. 体のハードウェア化による高速化の研究も行われてい. るが，その多くはユニプロセッサを対象としている．. 仲野らによるＳＴＲＯＮｇ)''０)は，リアルタイムＯＳである’1TRONの－部をハードウェア化することで高速化を目指したものである．ＳTRONでは，ＯＳの支. 援を行うハードウェアを導入することで高速化を行っ. ＳＳＨは集中，または分散共有メモリのマルチプロ. セッサ環境において，スレッドのスケジューリングをハードウェアで行うものである．ＳＳＨを用いたマルチ. プロセッサアーキテクチャを図１に示す．アーキテク. チャは,ＣＰＵとSSH-sを含む複数のＰＥ(Processing. E1ement)，スケジューリングを行うSSH-m，SSH-s. ている．しかしながら，導入しているハードウェアは. とSSH-mを結ぶスケジューラバス，スケジューラパ. ハードウェアで実現したサブルーチンであり，ＣＰＵ. ス調停機，メモリパス調停機，共有メモリから成る．. と協調処理を行うわけではない．一方，本稿で提案す. SSH-sは各ＣＰＵとSSH-mとのインターフェースを. る手法では，ＣＰＵで実行されるソフトウェア部分と. 提供するもので，ＣＰＵの動作と並行して次に実行す. 専用ハードウェアで実行される処理が並列に動作する. るスレッド情報の取得，新しいスレッド情報の送信等. 点が異なる．これにより，ハードウェアによる高速化. を行う．ＣＰＵとSSILsはオンチップでの実装を想定. だけでなく，処理時間の隠蔽も可能にしている．. しており，メモリマップド１０で接続する．. 本研究の様に，Linuxのマルチプロセッサ環境でスケジューリングをハードウェア化するものとしては. スレッドのスケジューリングはSSH-mで行う．ＳＳＨ－. ｍはＳＳＨｓを介してＣＰＵから送られて来たスレッ. BostonOircuits社のgCORE11)がある．ｇＣＯＲＥは. ド情報を管理し，優先度に従ってスケジューリングを. ネットワーク環境を模して相互接続した複数のプロ. 行う．SSH-sから要求があると，もっとも優先度の高. セッサコアを内蔵するマイクロプロセッサアーキテク. いスレッド情報をＳＳＨｓに返す．. チャでワンチップでグリッドコンピューティングを実. ＳＳＨ－ｍとSSH-sは調停器を備えた専用のスケジュー. 現する．ｇＣＯＲＥはＣＰＵへのスレッド割り当てを専. ラパスによって接続される．この調停器は，ＳＳＨｍか. 用回路,TimeMachineで行う．TimeMachineではスレッド情報の送受信をＣＰＵ間ネットワークを介して行うが，このＣＰＵ間ネットワークはメモリアクセ. らのパス使用要求を最優先とし，それ以外のSSH-sからの要求はラウンドロピンにより決定する．ａ２ＳＳＨの内部アーキテクチャ. ストランザクション,Ｉ／Ｏアクセストランザクション. ＳＳＨはスケジューリングなどの処理を行うＳＳＨ. の送受信にも使用するため，スケジューリングが多発. ｍとＣＰＵとSSH-mのインターフェースを提供する. する近細粒度並列処理ではメモリアクセス性能低下. SSH-sから構成される，ＳＳＨはクライアント・サー. を招く恐れがある．一方，我々のＳＳＨは専用のスケ. パーモデルになっており，SSH-mがサーバー，SSH-s. ジューラバスを備えるためスケジューリングの多発に. がクライアントとして動作する．本節ではこれらの詳. よりメモリアクセス性能が低下することはない．. 細なアーキテクチャについて述ぺる．３．２．１ＳＳＨ－ｍ. ３．ＳＳＨ. 本節では著者らの提案しているＳＳＨについて概括する．. 図２にSSH-mのブロック図を示す．ＳＳＨｍはスレッドのスケジューリングを行うHardwareScheduler. とスレッド情報を保持するG1obalQueueから成る． SSHはスレッドごとに４ワードのスレッド情報を保持する．この内１ワードは優先度やスレッドの状態等，. －２６－.

(3) ＣＰＵ. SｈａｒｅｄＭｅｍｏｒＹＢｕｓＳＳＨ－ｍＢｕｓ. Ｓｎｏｏｐｉｎｇ. Ｕｎｉｔ. ［⑩ｇｏＨＤ. ０口①ロ。. Ｈａｒｄｗａｒｅ. Ｓｃｈｅｄｕ１ｅｒ. ＳｃｈｅｄｕｌｅｒＢｕｓ図zＳＳＨ－ｍ. 図３ＳＳＨ－Ｂ. SSHがスケジューリングを行うための情報を保持し，. に送信する．. 残り３ワードはＯＳやスレッドライブラリがコンテキ. ３．３ＳＳＨの動作. スト情報へのポインタ等の任意の情報を保持させるこ. ＳＳＨの動作例を示す．初期条件として，実行開始か. とができる．G1obalQueueは優先度ごとに実行可龍状態のスレッドを保持するReadyQueue，待ち状態のスレッドを保持するWaitQueueをＳＲＡＭを用い. ら十分に時間が経っており，G1obalQueueには既に実行待ちのスレッドがあり，あるＳＳＨｓのReadQueue， WriteQueueは共に空であるとする．ユーザープログ. て実装する．. ラムがタイムスライスを使い切り，別のスレッドにコ. HardwareSchedulerはSSH-sからのコマンドに応. じてG1obalQueueヘスレッド情報のエンキュー，デ. ンテキストスイッチする際の動作を示す．. STEP1：ＣＰＵではユーザープログラムが動作して. キューを行う．. いる．これに並行してReadQueueが空であるこ. 3.2.2ＳＳＩＬｓ. とを検出したSSH-sはスケジューラパスの使用. 図３にSSH-sのブロック図を示す．SSH-sはＣＰＵ. 権を確保し，SSH-mに次に実行すべきスレッド. とSSH-mのインターフェースを行うCPU-SSHIn‐. terfaceUnit，スケジューラパスを介してSSH-mと. 情報を要求する．. S狂EP2：SSH-mはGlobalQueueの中で最も優先. 通信を行うSSH-SSHInterfaceUnit，SSH-mから取得したスレッド情報及び，SSH-mに送信するスレッ. 度が高いスレッド情報をSSH-sに返す． STEP38SSH-sはスレッド情報を受け取り，Read. ド情報を保持するためのRegisterUnitから成る．. Queueに格納する．. RegisterUnitはＳＳＨｓおよび，ＳＳＨ－ｍへのコマンドや，次に実行すべきスレッド情報を格納するRead. STEP48OSはスレッドがタイムスライスを使い切っ. たことを検出するとWriteQueueに現在のスレッ. Queue，新規に作成したスレッド，あるいは実行権限を手放したスレッド情報をＳＳＨｍが送信されるまで. ド情報を書き込む．. STEP5：ＳＳＨｓはWriteQueueにデータが書き込. 保持しておくWriteQueueから成る．. まれたのを検出し，パスの使用権を取得後,Write. OPU-SSHInterfaceUnitはＣＰＵが発行したロー. QueueのデータをSSH-mに送信する．ＯＳは. ド・ストア命令のメモリアドレスをRegisterUmtに. ReadQueueからから次に実行するスレッド情. マッピングし，内部レジスタの書き込み，読み出しを仲介する．. 報を取得し，コンテキストスイッチを行う．. SrEP6：SSH-sからスレッド情報を受け取ったＳＳＨ－. SSH-SSHInterfDceUnitはRegisterUnitを監視し，ReadQueueが空になると，SSH-mに要求を出し，次に実行すぺきスレッド情報を取得する．また， WriteQueueに有効なスレッド情報が入るとSSH-m. －２７－. ｍは，これを優先度別に適切なキューへ追加する．. （以後，再びSTEP1からの動作を繰り返す．）.

(4) ４．ＳＳＨのLinuxへの適用. レッドの管理方法をそのままハードウェア化する．す. なわち，SSH-mにG1obalQueueを２セット用意し，. ４．１方針. 片方をタイムスライスが残っているスレッド情報を保. Linuxは汎用ＯＳとして設計されているため，通常. 持するキュー(ReadyQueue)，もう片方をタイムスライスを使い切ったスレッドを保持するキュー(Expired. のタスクは優先度に応じてＣＰＵの割当てを行う変動プライオリティ型ラウンドロピンでスケジューリング. を行っている．一方，従来のＳＳＨでは，ハードウエ. Queue)とする．ＳＳＨｓに送信するスレッド情報の選択はReadyQueueから行い，タイムスライスを使い. アスケジューラではすべてのタスクをFIFＯポリシ. 切ったスレッド情報はExpiredQueueに格納する．そ. でスケジューリングし，スレッドライブラリ，あるい. してReadyQueueが空になったことを検出した時点. はＯＳ側でタイマー割り込みの使用，あるいは動的な. で２つのキューの役割を交代させる．. プライオリティの変更をすることで，ラウンドロピン. これにより，各プロセスに定期的にＣＰＵが割り当. は変動プライオリティ型ラウンドロピンの実現をして. てられることが保証される．そして，各スレッドにタイ. いた．. ムスライスが割り当てられる回数が等しくなり，割り. ここで，従来のＳＳＨ用pthread互換スレッドライプラリユ）では，変動プライオリティ型ラウンドロピ. また，従来のＳＳＨでは，全スレッドが待ち状態になっ. ンをＣＰＵの占有時間の長いスレッドの実効優先度を. 当てられるＣＰＵ時間のバランスが崩れることを防ぐ．. 徐々に下げていき，優先度の低いスレッドにもＣＰＵ時. てもタスクキューが溢れないように待ちキュー(Wait Queue)をReadyQueueと同程度の大きさを確保し. 間が与えられるようにすることで実現していた．しか. ていた．一方，本稿で実装するLinuxスケジューラ. し，この手法では優先度が高いスレッドと低いスレッ. では本質的にWaitQueueが不要になるため，従来の. ドの間の優先度が差が大きい場合に優先度の高いス. WblitQueue分のメモリをReadyQUeueに割当てる. レッドの実効時間が著しく長くなるという問題があっ. ことで，ハードウェア量を増やすことなくLinuxス. た．一方，Linuxでは一度タイムスライスを使い切っ. ケジューラを実現できる．４．２改良型ＳＳＨの動作. たスレッドはシステム上の他のスレッドもタイムスラ. イスを使い切るまでは，新たにタイムスライスを割り当てないようにすることでこの問題を解決している．. 改良型ＳＳＨではＳＳＨｍがReadyQueueとＥｘ‐ piredQueueの二つの優先度別のキューを持つ．ＳＳＨ. また，我々のpthreadライブラリでは割り当てられ. ｍの構造を図４に示す．改良型ＳＳＨではタイムスラ. るＣＰＵ時間の長さが各スレッドに割り当てられた優. イスを使い切ったか否かという情報と共にSSILsから. 先度ではなく，他のスレッドの優先度との差に比例す. スレッド情報が送れてくる．SSH-mはこれにより，タ. るという性質があった．しかし，Ｌｍｕｘではタイムス. イムスライスが残っているものはReadyQueue，使い切ったものはExpiredQueueの該当する優先度の. ライスの長さはユーザーが与える静的優先度★によってのみ決定される．. 従来のpthreadライブラリの実装をそのままLinux. キューに挿入する．一方，SSH-sからスレッド情報の. 要求があると，ReadyQueueの空でない最も優先度. に適用しても，静的優先度の高いスレッドも時間経過. が高いキューの先頭からスレッド情報を取り出し，要. と共に一時的に動的優先度を下げていくため，低い静. 求したSSH-sに返す．. 的優先度のスレッドが永久に実行されないという問題. この動作を繰り返すとやがてReadyQueueの全てのキューが空になる．SSH-mはこれを検出し，Ready QueueとExpiredQueueの役割を交代させる．. は発生しないしかしLinuxの標準のソフトウェアス. ケジューラと比較すると，各スレッドに割り当てられるＣＰＵ時間のバランスが大きく崩れてしまう可能性. ５．性能見積もり. がある．これらの問題はもともと従来のpthread互換スレッドライブラリ及び，ＳＳＨがタイムスライスの. ＳＳＨを利用することでLinuxはスケジューリング. 概念をもたないため，タイムスライスを使い切ったス. を行う際に次に実行するスレッドを決定する処理と従. レッドをうまく扱えないことに起因している．. 来ソフトウェアで実現してたReady/ExpiredQueue. そこで本研究ではＳＳＨを改良し，Linuxのスケ. に関する操作に要する時間を削減することができる．. ジューラが採用するタイムスライスを使い切ったス. 本節では評価環境を示したあと，タイマー割り込みごとに発生するタイムスライス更新に関する処理と. ★ｎｉｃｅシステムコールによってのみその値が変更される．. Linuxのスケジューリング処理を受け持つschedule. －２８－.

(5) ＳＳＨ－ｍ. 上ｉｍｅｓｌｉｃｅ. ｎｒｅａｄｈａｓ. ｉｍｅｓ１ｉＣｅ「. 表３schedule関数の処理に要するサイクル数とその内訳. ReadyQueueBwitchabユロBxpiredQueue (ｏｒｒａｙｏｒＦｪFoB）￣ぃｒｒｎｙｏｆＦｪFOB）. プロファイル情報更新. 唾二三+ｌｉｉ. Ready/ExpiredQueue操作次スレッド決定. 動的優先度再計算コンテキストスイッチ. その他計. 麺狸麹蛭唖》｜趣. 上ｈｒｅａｄｈａｓ. ｓｃｈｅｄｕｌｅｒｂｕｓ. Linuxの標準のソフトウェアによるReady/Expired. 図４改良型ＳＳＨ－ｍ. Queue実装ではＣＰＵごとにキューを用意し,各スレッ. ドが同じＣＰＵのReady/ExpiredQueueに保持され. 表1評価環境ＣＰＵ. R3000互換プロセッサ２台. １ｉｈ作周波数. １０ＭＨｚ. 主記憶. ６４ＭＢ. ＯＳ. ｍｉｒｌｕｘ２､６．１０. コンパイラ. ＧＣＣ3.4.4. Verilogシミュレータ. ＶＯＳ７．０. 続ける様になっている．これにより，スレッドが複数. のＣＰＵの間を動き回ることを避け，キャッシュメモリのヒット率を上げている．しかしこの手法では各プロセッサに割り当てられたスレッド数に偏りが生じる. 場合があるため，偏り大きくなったことが検出されると負荷の高いＣＰＵから低いＣＰＵにスレッドを移動させバランスをとる．タイマー割り込みハンドラの中. 表２タイマー割り込みに要するサイクル数とその内訳割り込みハンドラ起動処理. １３３７. でもこのパランシング機構に関連した処理が行われる．. プロファイル情報の更新タイムスライス更新. }霊；. Queueを使用するのでこのパランシング処理は必要. ソフト割り込みハンドラ. ５３１. ない．これによりタイマー割り込み処理に要するサイ. その他. 3235. 計. 11107. パランシング処理. しかし，ＳＳＨでは全ＣＰＵで共通のReady/Expired. ３６０７. クル数を約32％削減できる．また，このパランシング. 処理はプロセッサ数に対しＯ(､)で計算時間が増加するアルゴリズムを含んでいるのでプロセッサ台数が増. 関数のそれぞれについてどの程度の性能向上が期待で. 加するとＳＳＨによる高速化率はさらに上がる．. きるか議論する．. ５．３schedule関数. ５．１評価環境諸元. schedule関数は次に実行すべきスレッドを決定し，. 評価環境の概要を表１に示す．. コンテキストスイッチを行う関数で，スレッドがタイ. ＣＰＵにはＲ3000互換のⅢＳｃプロセッサを２台搭載する．このプロセッサはTbst-and-Set型の独自のア. ムススライスを使い切ったときや，何らかの原因でブ. ロックされるときに呼び出される．schedule関数にか. トミックなロード･ストア命令を備え，マルチプロセッ. かるサイクル数とその内訳を表３に示す．. サに対応する．キャッシュコントローラは現在開発中であるため，今回はキャッシュのヒット率を100％と. に対する操作,次に実行すべきスレッドの決定Ａｕ理を数. 仮定して評価を行った．また，主記憶は６４ＭＢとす. サイクルで終えることができる．これによりschedule. る．この環境をＶｅｒｉｌｏｇＨＤＬを用いて実装し，シミュ５．２タイマー割り込み処理. 関数に要するサイクル数を約１８％削減できる．更に著者らの提案しているコンテキストスイッチ支援ハードウエアＣＳＳを適用することで，最大で35％の削減を. 標準ではLinuxは毎秒1000回★のタイマー割り込. 期待できる．. レータ上で動作させ評価を行った．. みを発生させる．しかし，本評価環境は動作周波数が低いので割り込み処理に要するサイクル数を減らすた. ＳＳＨを使用することにより，Ready/ExpiredQueue. また，ソフトウェアによるReady/ExpiredQueue. 実装ではschedule関数内でＣＰＵがアイドル状態で. め，これを100回に落として評価を行った．本評価環境ではタイマー割り込み処理一回当たり11000サイ. あることを検出すると他の負荷の高いプロセッサを探し，そのプロセッサに張り付いているスレッドを奪う．この処理はパランシング処理と同様にプロセッサ台数. クル程度要した．その内訳を表２に示す． ★2.6.13以降は２５０回. に対しＯ(､)で計算時間が増える．ＳＳＨではこのような処理は必要ないためプロセッサ台数が増えた場合に. －２９－.

(6) }まさらなる高速化が望める．. ６．結論と今後の展望ＳＳＨを利用してLinuxのスケジューリングを行う方. タイムＯＳチップの性能評価と分散ＯＳへの拡. 張,電子情報通信学会技術報告書,VOLOPSY51,pp23-30(1998)． 10）Nakano,Ｔ､,Komatsudaira,Ｙ､,Shiom,Ａａｎｄｌｍａｉ,Ｍ､：PerfbrmanceEvaluationofSTRON： AHardwarelmplementationofaReaﾙＴｉｍｅＯＳ，IEIOEnalmsactions,Vol・E82-A，Ｎｏ．１１，. 法を検討し，高速化が可能であることを示した．現在， SSHを利用してスケジューリングを行うスケジューラ. を実装中であり，完了次第，詳細な評価を行う予定である．. また，現在のＳＳＨはLinuxの標準のスケジューラで行われていた，スレッドのＣＰＵへの貼り付けが考慮されていない．今後はこの点も考慮してスケジューリングを行い，キャッシュヒット率の向上をねらう．. 参考文献. １）佐々木敬泰,西村直已,弘中哲夫,吉田典可：. マルチプロセッサ用スケジューリング支援ハード. クでＣＰＵコアをつなぐマルチコア型マイクロプ. withSchedulingSupportHardwarefbrOperatingSystemonMultiprocessorSystem，Asia andSouthPacificDesignAutomationConfer-. ence2000(ASP-DAO2000),pp29-30(2000)．３）DStein,Ｄ・Shah:ImplementingLightweight Threads，USENIXOonferenceProceedings，. ppl-10(1992)．４）ＫＩＥｕｒａａｎｄＡ・Ybnezawa:Fme-grainmul‐. tithreadingwithminimalcompilersupportacosteHectiveapproachtoimplementingeflicientmultithreadinglanguages,Ｐｒｏｃｅｅｄｉｎｇｓｏｆｔｈｅｌ９９７ＡＯＭＳＩＧＰＬＡＮOonfbrenceonPro‐. grammingLanguageDesignandlmplement趾. tion,pp､320333(1997)．５）ＭＬ・PowelleM.:SunOSMulti-threadAr‐ chitecture，USENIXOonferenceProceedings，ｐＰｌ－１３(1991)．. ６）飯田全広,久我守弘,末吉敏則:マルチスレッド制. 御ライブラリのハードウェア化によるオンチップ・. マルチプロセッサの構成,並列処理シンポジウム（JSPP'971PSJSymposiumSeries),pp337L344 （1997）７）坂本力，宮崎輝樹,桑山雅行,最所圭三,福田晃:並例性と移植性をもつユーザレペルスレッドラ. イプラリーＰＰＬの設計および実装,電子情報通信学会論文誌,VOLJ80-D-I,Nol,ｐｐ､42-49(1997)，８）小熊寿，海江田章裕，森本浩通，田村友彦，. 鈴木貢，中山泰一:ＳＭＰ型計算機を活用する軽量プロセス・ライブラリ，情報処理学会論文誌， VOL39,Ｎ09,ｐｐ､2718-2725(1998)．９）仲野巧,小松平良樹,塩見彰陸,今井正治リアル. －３０－. ●. △ｍ一一（叩叩》（叩皿》（四二］. 。ⅢＢ■〃〃. ロセッサを開発，日経ＢＰ日経エレクトロニクス９月２６日号ppl79-186(2006)． 12）DanielＰ・Bovet,MarcoCesati:詳細Linux カーネル第２判,オライリー・ジャパン(2003)． 13）JoshAaB;UnderstandingtheLmux2､6.8.1 OPUScheduler,ｈ伽:(/ﾂosh.tmnce3q/f⑩….com/1伽uZ／ (2005)． 14）高橋和宏:Linuxカーネル2.6溺騨室第１回プロセススケジューリング，ソフトパンクパブリッシングＵＮＩＸＵＳＥＲ２００４年６月号ｐｐ,89106 〃８０Ⅱ、. ウェアの提案とシミュレーション評価,電子情報通信学会論文誌,VbLJ84D-I,No.11,ppl515-1531 （2001)．２）NaokiNishimura,IhkahiroSasakiandlbt‐ suoHironaka：PrototypeMicroprocessorLSI. pp2375-2382(1999)． 11）AronKurland,片岡裕之,梅村誠:ネットワー.

(7)