JP2010113524A - コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 - Google Patents
コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 Download PDFInfo
- Publication number
- JP2010113524A JP2010113524A JP2008285653A JP2008285653A JP2010113524A JP 2010113524 A JP2010113524 A JP 2010113524A JP 2008285653 A JP2008285653 A JP 2008285653A JP 2008285653 A JP2008285653 A JP 2008285653A JP 2010113524 A JP2010113524 A JP 2010113524A
- Authority
- JP
- Japan
- Prior art keywords
- kernel
- operating system
- resource
- resources
- computer system
- 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.)
- Granted
Links
Images
Landscapes
- Multi Processors (AREA)
- Debugging And Monitoring (AREA)
Abstract
【解決手段】コンピュータシステム100は、リソースと、リソースに対するアクセスを供給する複数のオペレーティングシステム101〜106を実行する複数のプロセッサとを備える。リソースは、プリンタ、ディスクコントローラ、ネットワークコントローラ、及び他の頻繁にアクセスされるリソースを含む。各オペレーティングシステムは、カーネルスケジューラを備える。複数のカーネルスケジューラは、互いに、コンピュータシステム上のプロセス実行に対するリソースの割当を調整する。
【選択図】図1
Description
カーネルの主な仕事は、アプリケーションの実行を許可し、例えばハードウェアを抽象化する機能によって、アプリケーションを支援することである。プロセスは、アプリケーションがどのメモリ部分にアクセスできるかを定義する(この導入部では、プロセス、アプリケーション及びプログラムは、同義語として用いられている)。カーネルのプロセス管理は、メモリ保護が組み込まれたハードウェアを考慮しなければならない。
オペレーティングシステムには、通常、カーネル、すなわちコンピュータの中核として動作する一群の中心的な制御プログラム(centralized control program)が組み込まれている。これらの制御プログラムの中には、次のプロセスに対してCPU時間を直列に予約する役割を果たすスケジューラプログラムが含まれている。本発明は、1CPU当たり1オペレーティングシステムであって、複数のCPU上で動作する複数のオペレーティングシステムを用いる。各オペレーティングシステムは、カーネル動作スケジューラ(Kernel Operational Scheduler:KOS)と呼ぶ独特なスケジューラプログラムを有する専用のカーネルを有する。全てのKOSは、初期化中に、それ自体を構成する能力を有し、コンピュータシステムに搭載されている各CPU用のオペレーティングシステムカーネル(operating system kernel)のバイナリコードのコピーをシステム生成(sysgen)する(システム生成とは、特定の、独自に定められたオペレーティングシステム、又は独立したソフトウェアコンポーネントを組み合わせることによって、他のプログラムを生成することを意味する)。各カーネルが、一旦、適切に準備されて、各CPUに連結されると、KOSスケジューラ(KOS schedulers)は、各カーネル間の通信を確立し、どのカーネルがどのリソースを制御するかを決定する。
上述したタスク及び特徴は、当然、設計及び実装が互いに異なる様々な方法で提供することができる。
モノリシックカーネルのダイヤグラム
モノリシックカーネルでは、全てのOSサービスは、主要なカーネルスレッド(kernel thread)と一緒に動作し、したがって、同じメモリ領域に存在する。この方法は、豊かで強力なハードウェアアクセスを提供する。何人かの開発者、例えばUNIX(登録商標)開発者であるケン・トンプソン(Ken Thompson)は、他の解決法に比べて、モノリシックカーネルのオペレーティングシステムは、設計及び実装が容易であると主張している。モノリシックカーネルの主な短所は、オペレーティングシステムのコンポーネント間の依存性、例えばデバイスドライバにおけるバグがオペレーティングシステム全体をクラッシュさせる可能性があり、大きなカーネルは、保守が非常に難しいという事実がある。
マイクロカーネル法(microkernel approach)では、カーネル自体は、以前のカーネルの機能、例えばデバイスドライバ、GUIサーバ等を承継した独立のプログラムをサーバが実行できるようにする基本機能だけを備える。
コンピュータのカーネルが進化するにつれ、幾つかの問題が明らかになってきた。最も明白な問題の1つは、メモリ使用量(footprint)が増えるということである。これは、仮想メモリシステムを改良することによって、ある程度軽減されるが、全てのコンピュータアーキテクチャが仮想メモリをサポートしているわけではない。カーネルのメモリ使用量を少なくするためには、大規模な編集を行い、不必要なコードを注意深く除去する必要があり、これは、数百万ものコード行を有するカーネルの部分間の相互依存性が理解し難いので、非常に困難である。モノリシックカーネルが抱える問題のために、モノリシックカーネルは、1990年代初頭には、時代遅れであるとみなされていた。この結果、マイクロカーネルではなく、モノリシックカーネルを採用したLinux(商標)の設計は、リーヌス・トーヴァルズ(Linus Torvalds)と、アンドリュー・タネンバウム(Andrew Tanenbaum)との間の有名な議論の主題となった。タネンバウム/トーヴァルズ議論では、何れの意見にも長所があった。初期のUNIXの開発者ケン・トンプソン(Ken Thompson)を含む何名かは、マイクロカーネル設計は、美的に魅力があるが、モノリシックカーネルの方がより簡単に実装できると主張した。しかしながら、モノリシックカーネルのオペレーティングシステムにおけるバグは、通常、オペレーティングシステム全体をクラッシュさせ、一方、サーバがメインスレッドとは別に動作するマイクロカーネルでは、このようなことは起こらない。モノリシックカーネルの支持者は、間違ったコードがカーネルに入ることはなく、また、マイクロカーネルは、コードが正しいことによる利点を殆ど提供しないと結論づけている。マイクロカーネルは、多くの場合、クラッシュに対する耐性(crash tolerance)が重要な埋め込み型のロボット用コンピュータ又は医療用コンピュータにおいて用いられており、殆どのOSのコンポーネントは、それ自体に専用の保護されたメモリ空間に存在する。これは、モノリシックカーネルでは不可能であり、最新のモジュールローディングのモノリシックカーネルでも不可能である。
モノリシックカーネルは、システム性能を高めるために、そのコードの全てを同じアドレス空間(カーネル空間)に有するように設計されている。何人かの開発者、例えばUNIXの開発者のケン・トンプソンは、モノリシックカーネルのオペレーティングシステムは、プログラムを上手く書けば、非常に効率が良いと主張している。マイクロカーネル設計における、通常メッセージパッシング(message passing)に基づくプロセス間通信(IPC)方式は低速であり、モノリシックモデルは、このIPCではなく、共有カーネルメモリを用いることによって、より効率が良い傾向にある。
ハイブリッドカーネル法(hybrid kernel approach)は、モノリシックカーネルの速さ及び設計の容易さを、マイクロカーネルのモジュール性及び実行時の安全性と組み合わせることを試みたものでである。
ナノカーネルは、割込コントローラ、すなわちタイマのような最も基本的なサービスさえも含む全てのサービスを、実質的に、デバイスドライバに委ね(delegate)、カーネルに必要なメモリを、従来のマイクロカーネルよりも更に少なくしている。
エクソカーネルは、ハードウェアを理論モデルに抽象化しない種類のカーネルである。論理モデルの代わりに、エクソカーネルは、物理的ハードウェアリソース、例えばCPU時間、メモリページ及びディスクブロックを異なるプログラムに割り当てる。エクソカーネル上で動作するプログラムは、エクソカーネルを用いて周知のOSの抽象化をシミュレートするライブラリオペレーティングシステムにリンクすることができ、あるいは、性能を高めるために、特定用途向けの抽象化を行うことができる。
スケジューリングは、コンピュータのマルチタスク及びマルチプロセスオペレーティングシステム設計、並びにリアルタイムオペレーティングシステム設計におけるキーコンセプト(key concept)である。スケジューリングは、優先順位付きキュー(priority queue)の優先度を、プロセスに割り当てる方法である。この割当は、スケジューラとして知られているソフトウェアによって実行される。
オペレーティングシステムは、長期スケジューラ(別名、入力スケジューラ(admission scheduler))、中間的又は中期スケジューラ、及び短期スケジューラ(別名、ディスパッチャ(dispatcher))といった最大3つの異なる種類のスケジューラを備えることができる。
スケジューリング規則は、同時且つ非同期でリソースを必要とするパーティ間に、リソースを割り当てるために用いられるアルゴリズムである。スケジューリング規則は、(スレッド及びプロセス間でCPU時間を共有する)オペレーティングシステムだけでなく、(パケットトラヒックを処理する)ルータにおいても用いられる。
異なるコンピュータオペレーティングシステムは、異なるスケジューリング方式を実装している。MS−DOS及びマイクロソフトの非常に初期のWindowsシステムは、マルチタスクではなく、それ自体は、スケジューラを必要としなかった。Windows3.1ベースのオペレーティングシステムは、単純なノンプリエンプティブスケジューラ(non-preemptive scheduler)を使用しており、プログラマは、CPU時間を他のプロセスに与えるために、CPU時間を明け渡す(yield、CPUを解放する)ように、プロセスに命令することが必要であった。このノンプリエンプティブスケジューラは、マルチタスクを原始的にサポートしているが、より高度なスケジューリングの選択肢を備えていなかった。
コンピュータ科学において、スケジューリングアルゴリズムは、システムリソース、通常はCPU時間に対するアクセスを、スレッド又はプロセスに与える方法である。スケジューリングアルゴリズムは、通常、システムに負荷を効率的に分散するために行われる。スケジューリングアルゴリズムの必要性は、マルチタスクを実行する、すなわち複数のプロセスを同時に実行する最新のオペレーティングシステムの殆どの要求から生じている。スケジューリングアルゴリズムは、通常、タイムスライス多重化カーネル(time slice multiplexing kernel)においてのみ用いられる。この理由は、システムに負荷を効率的に分散させるためには、タイムスライス多重化カーネルは、次のスレッドの実行を開始するために、現スレッドの実行を強制的に中断(suspend)できなければならない。
この章は、I/Oスケジューリングに関する説明であり、I/Oスケジューリングは、プロセススケジューリングとは異なるものである。I/Oスケジューリングは、ブロックされたI/O動作をディスクサブシステムに送る順番を決定するために、コンピュータオペレーティングシステムで用いられる方法を記述する用語である。I/Oスケジューリングは、ディスクスケジューリング(disk scheduling)とも呼ばれる。
I/Oスケジューラ(I/O scheduler)は、I/Oスケジューラの目標に応じて、多くの目的を有することができ、以下、共通の目標を示す。
・特定のプロセスのI/O要求を優先させる。
・ディスク帯域幅を動作中の各プロセスに割り当てる。
・特定のデッドラインの前に、ある要求が発行されることを保証する。
I/Oスケジューリングは、通常、ハードディスクによって機能しなければならず、ディスクヘッドを現在の位置から遠く離れた位置に移動する(この動作は、シークと呼ばれる)要求のために、アクセス時間が長くなるという特性を有する。このシーク動作がシステム性能に与える影響をできるだけ少なくするために、殆どのI/Oスケジューラは、ランダムな順番で入力された要求を、ディスク上で検出される順番に並べ替える種々のエレベータアルゴリズム(elevator algorithm)を実装している。
・ランダムスケジューリング(Random Scheduling:RSS)
・先入先出(First In, First Out:FIFO)、別名、先着順サービス(First Come First Served:FCFS)
・後入先出(Last In, First Out:LIFO)
・最短シーク順(Shortest seek first)、別名、最短シーク/サービス時間順(Shortest Seek / Service Time First:SSTF)
・エレベータアルゴリズム(Elevator algorithm)、別名、SCAN(その変種C−SCAN、LOOK及びC−LOOKを含む)
・一度にN個のレコードをスキャンするNステップSCAN(N-Step-SCAN)
・FSCAN、NがSCANサイクルの最初のキューサイズに等しいステップSCAN(Step-SCAN)
・完全公平キューイング(Completely Fair Queuing:CFQ(Linux))
・予測スケジューリング(Anticipatory scheduling)
マルチタスクにおいて、カーネルは、コンピュータが物理的に同時に動作させることができるプロセスの最大の数よりも多くのプロセスがコンピュータ上で同時に動作しているような錯覚を、ユーザに与えることができる。本発明は、この錯覚を、プロセッサの数を1つから2つ以上に増やすことによって現実のものとし、イベントを、リソースを要求するイベントとして、通信、スケジューリング、委託(delegated)、ルーティング及び外注(outsource)する特別に設計されたスケジューラソフトウェアを用いて、互いに同時に機能する、コンピュータシステムに実際に搭載されたオペレーティングシステムの数を増やすKOS設計を実際に提案する。通常、オペレーティングシステムが同時に動作させることができるプロセスの数は、搭載されているCPUの数に等しい(なお、プロセッサが同時マルチスレッディングをサポートしている場合は、この限りではない)。本発明の好ましい実施の形態は、複数のCPUが搭載されていることを必要とし、最大の性能を発揮するためには、協調して同時に機能するオペレーティングシステムの数が、搭載されているCPUの数に等しくなければならないことを、提案する。また、UNIX−KOS設計も、各オペレーティングシステムカーネル内でマルチスレッディングが実行され続けることを提案しているが、KOSスケジューラは、アプリケーションによって必要とされるリソース及び各オペレーティングシステムによってサポートされているリソースに基づいて、アプリケーションプログラムを、インストールされている各オペレーティングシステムに/から通信、外注及びルーティングすることが残されている。
分散カーネル動作スケジューラ(分散KOS)は、他のカーネル動作スケジューラと同期して動作する分散オペレーティングシステムである。各KOSは、他の同様なKOSと並列して動作し、ある所定のコンピュータシステム環境内には2つ以上のオペレーティングシステムがあり、ある特定のコンピュータには2つ以上のCPUが存在するが、これらの環境は、シングルコンピュータシステムとみなされる。幾つかの用語法(nomenclature)では、分散コンピューティング(distributed computing)とは、コンピュータリソース(computing resources)が多くの異なるコンピュータプラットフォームに分散され、全てのコンピュータリソースが、1つの主題の下に協調して(in concert)機能するものと定義される。KOSは、これに類似しているが、分散KOSは、シングルコンピュータシステム環境内にあり、互いに非常に密接し、シングルコンピュータシステムとして動作する点だけが異なる。各KOSは、単一カーネル内にある。各カーネルは、単一のスケジューラを有し、この単一スケジューラは、KOSが、イベントをスケジューリングする種類の他の同様のKOSと通信する通信機能を有するように設計された後は、このKOSによって置換される。
IPC機能及びプロトコルスタック(IPC Facilities and Protocol Stacks)
IPC機能及びプロトコルスタックは、UNIX構造に常駐し、ユーティリティとして既に統合されている。これらのユーティリティは、UNIX構造の下で、オペレーティングシステム間の通信を行うために、用いられる。
カーネルスケジューラは、現処理をどこで行うかを決定するために必要とされるリソースをフィルタリングし、選択する機能を有する。例えば、各CPUは、通常、汎用のCPUであり、それに対して、各KOSは、より特化されている。ポインタ及びファイル記述子(file descriptors)が、実際のファイルデータの代わりに、各KOS間で受け渡されるように、メモリの一部は、各KOS間で共有される。IPC機能を用いることによって、任意のプロセスを、複数のCPUに亘って、及び複数のKOSに亘って移動させることができ、したがって、必要なトランザクションを、プロセス間のトランザクションプロトコル(Transactional Protocol)の形式で移すことができる。
共有メモリは、現在のUNIX構造の非常に不可欠な部分であり、現在、特定の規則(particular convention)で使用するようになっているが、共有メモリは、また、KOS、現在の規則の下に、分散OSの目的で機能するように特定の方法で実装することができる。本発明の一実施の形態では、各オペレーティングシステムカーネルには、スケジューラが組み込まれており、スケジューラは、各カーネルの不可欠なキーコンポーネントプレーヤになっている。各分散オペレーティングシステムのKOSは、KOSスケジューラになっている。4つのこのようなスケジューラを有する4つのこのようなオペレーティングシステムがある場合、各スケジューラは、他のオペレーティングシステムの他のスケジューラと通信するように設計されている。この通信は、他のスケジューラのリソースを共有できるように設計されている。各スケジューラは、リソースの特定のセットに接続(attached)されており、この特定のセットには、典型的なコンピュータリソース、例えばディスクアクセス、インターネットアクセス、映画DVDプレーヤ、音楽DVD、キーボード通信等が含まれる。これらのリソースは、オペレーティングシステムのカーネルスケジューラの所定のセットに接続されており、スケジューラのそれぞれは、特定の所定の時点(specific given point)で、特別なリソースを必要とする特定の処理を、他のCPU上で動作している他のKOSに外注又はオフロード(off-load)することができる。各スケジューラには、メモリの一部が割り当てられる。スケジューラ及びそのカーネルは、他のKOSと共に、メインメモリ及びそれらのCPUにマッピングされている。
TCP/IPローカル(TCP and IP local)は、データ及びアプリケーションファイルをCPUとKOS間で転送するリソースとして用いることができる。各KOSは、それ自体のCPUに局所的であり、独立したメモリがマッピングされたI/Oを有していてもよく、有していなくてもよい。一実施の形態では、多くのUNIXシステムに常駐しているTCPポートのループバック機能(TCP Port loop-back facility)が用いられ、このTCPポートのループバック機能は、KOSシステム構成の下に他のオペレーティングシステムとの間でデータファイルを送受信するように構成されている。
ユーザデータグラム(UDP:User datagram)、ユーザ定義プロトコル(user defined protocol)は、TCP/IPプロトコル群の一部であり、KOS規則の下に、独立したCPUとオペレーティングシステム間でデータファイルをインポート及びエクスポートするように構成することができる。また、UDPは、独立したCPUに常駐するオペレーティングシステム間でメッセージを受け渡すように構成することができる。
I/Oバスコントローラは、特殊用途のデバイスとして機能するが、また、ディスクの動作、あるいはメインメモリの入力又は出力用のチャンネルデータの処理に関係した特定のタスクに固有のタスクを指示する(directs)。このようなコントローラは、より機能的な能力を有し、常駐ソフトウェア、例えばKOSが、ハードワイヤードな(hard wired)アプリケーションではなく、再構成可能なアプリケーションを特定のコントローラに提供することができる汎用のCPUによって、容易に置き換えることができる。本発明の実施の形態において、I/OCPU又はプロセッサは、一般のシステムのI/O機能のみを処理するように特に設計されたスケジューラを有するI/Oオペレーティングシステムを常駐させる。これによって、バスデータは、CPUが必要条件としてI/Oキューを形成する能力を有するので、コントローラにおけるボトルネックを回避することができる。
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに「記憶」される。
プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。この状態では、プロセスは、「実行可能(ready)」状態に入る(admission)のを待っている。この入力(admission)は、長期スケジューラ、すなわち入力スケジューラによって、承認又は遅延される。通常、殆どのデスクトップコンピュータシステムでは、この入力は、自動的に承認されるが、リアルタイムオペレーティングシステムでは、この入力は、遅延される場合がある。リアルタイムオペレーティングシステム(real-time operating system:RTOS)では、「実行可能」状態に余りにも多くのプロセスを入れると、過飽和になり、システムリソースの競合が始まり、結果として、プロセスのデッドラインに間に合わなくなることを避けることができなくなる。
「実行可能」プロセス又は「実行待ち」プロセスは、既にメインメモリにロードされており、CPU上で実行されるのを待っている(ディスパッチャ、すなわち短期スケジューラによって、CPUにコンテキストスイッチが起こる)。システムの実行のある時点において、「実行可能」プロセスが数多くある場合がある。例えば、シングルプロセッサシステムでは、同時に実行できるプロセスの数は1つだけであり、他の全ての「同時実行(concurrently executing)」プロセスは、実行されることを待っている。
「動作(running)」プロセス、「実行(executing)」プロセス又は「活動(active)」プロセスは、現在CPU上で実行されているプロセスである。この状態から、プロセスは、それに割り当てられたタイムスライスを超えると、オペレーティングシステムにより、コンテキストスイッチアウトされて、「実行可能」状態に戻される。なお、このプロセスは、完了又は終了され、あるいは幾つかの必要なリソース(例えば入出力リソース)によりブロックされて、「ブロック」状態に移行することもある。
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されると、そのプロセスは、CPUから除去されて、ブロック状態になる。プロセスは、そのリソースが利用可能になるまで、「ブロック」されたままであり、最悪の場合には、デッドロック(deadlock)とされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、オペレーティングシステムが、プロセスが最早ブロックされていないことを知ると、プロセスは、再び「実行可能」状態になり、この実行可能状態から「実行」状態にディスパッチされることが可能になる。実行状態になってから、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
プロセスは、「実行」状態から、その実行を完了させることによって、あるいは明示的に強制終了(kill)することによって、終了させることができる。何れの場合も、プロセスは、「終了」状態に移行する。この終了状態に入った後にも、プロセスがメモリから除去されない場合、このような状態は、「ゾンビ(zombie)」とも呼ばれる。
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらのプロセス状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
仮想メモリをサポートしているシステムでは、プロセスは、スワップアウトすることができ、すなわち、プロセスは、中期スケジューラによって、メインメモリから除去されて仮想メモリに置かれる。そして、仮想メモリから、プロセスを、実行待ち状態にスワップバックすることができる。
ブロックされているプロセスは、更に、スワップアウトされることもある。この事象(event)において、プロセスは、ブロックされた上にスワップアウトされており、スワップアウト及び実行待ちプロセスは、同じ状態にスワップバックすることができる(すなわち、この場合、プロセスは、ブロック状態に移行し、リソースが利用可能になるのを待っている)。
マルチタスクのカーネル(Linux等)では、複数のプロセスが常に存在することができ、各プロセスは、システム上でただ1つのプロセスであるかのように動作することができる。プロセスは、明示的に設計されない限り、他の如何なるプロセスも意識する必要はない。これにより、プログラムを容易に開発し、保守し、移植することができる。システム内の各CPUは、一度に、プロセス内の1つのスレッドしか実行することができないが、多くのプロセスからの多くのスレッドが同時に実行されているように見える。これは、スレッドが非常に短い時間動作するようにスケジューリングされ、そして、他のスレッドに動作の機会を与えるためである。カーネルのスケジューラは、スレッドのスケジューリングポリシを実施し、そこには、いつ、どれくらいの長さで、場合によっては(SMPシステム上の)どこでスレッドを実行できるかを含んでいる。通常、スケジューラは、それ自体のスレッドで動作し、このスレッドは、タイマ割込によって起動される。あるいは、このスレッドは、システムコール又はCPUを明け渡すことを望む他のカーネルスレッドによって呼び出される。スレッドは、ある程度の時間実行することが許され、そして、スケジューラスレッドへのコンテキストスイッチが起こり、続いて、スケジューラが選択するスレッドへの他のコンテキストスイッチが行われる。このサイクルは、繰り返され、この方法では、CPU使用のための特定のポリシが遂行される。
スレッドの実行は、CPUバウンドとI/Oバウンド(Input/Output bound)との何れかとなる傾向がある。すなわち、幾つかのスレッドは、計算を実行するために長い時間CPUを用い、他の幾つかのスレッドは、比較的遅いI/O動作を完了するために長い時間待機する。例えば、DNA配列スレッド(thread sequencing DNA)は、CPUバウンドである。文書処理プログラム(word processing program)の入力を行うスレッドは、人間がタイプするのを待つために多くの時間を費やすので、I/Oバウンドである。スレッドがCPUバウンドであるか、I/Oバウンドであるかは、常に明確でない。スケジューラが、何れのスレッドであるかを本当に考慮しても、スケジューラが行える最高のことは、推測することである。多くのスケジューラは、スレッドがCPUバウンドとみなすべきか否か、I/Oバウンドとみなすべきか否かについて検討し、したがって、スレッドをどちらか一方に分類する技術は、スケジューラにとって重要な要素である。スケジューラは、CPUにアクセスする優先権を、I/Oバウンドなスレッドに与える傾向がある。人間の入力を行うプログラムは、I/Oバウンドな傾向があり、最も速いタイピストであっても、各キーストローク間にかなりの時間がかかり、タイピストがインタラクトするプログラムは、この間は単に待っているだけである。人間が速やかな応答を期待してる場合、速度及び応答が遅いと、それに気付かれるので、人間とインタラクトするプログラムに優先度を与えることが重要である。
スケジューリングは、タスクに一連のリソースを割り当てるプロセスである。スケジューリングは、多くの分野、例えば計算プロセス及び生産プロセスにおいて、重要な概念である。
一旦、プロセスにCPUが与えられ、そのプロセスがCPUを持ち続ける場合は、スケジューリング規則は、ノンプリエンプティブである。ノンプリエンプティブスケジューリングの幾つかの特徴を以下に記す。
a.プロセスが実行状態から実行待ち状態に切り換わったとき
b.プロセスが終了したとき
一旦、プロセスにCPUを与えられても、CPUが取り上げられる可能性がある場合、スケジューリング規則は、プリエンプティブである。論理的には動作可能なプロセスを一時的に停止することを許可する戦略(strategy)は、プリエンプティブスケジューリングと呼ばれ、完了するまで動作させる(run to completion)方法と対照的である。
有効時間の総時間=8ms/l0ms=80%、すなわち、CPU時間の20%がオーバヘッドに浪費されている。
・応答時間−プロセスが完了する時間。OSは、ある種のプロセスを好み、又は平均待ち時間のような統計的特性を最小にすることを望む。
・実行時間(Implementation Time)−これは、アルゴリズム及び保守の複雑性を含む。
・オーバヘッド−どのプロセスをスケジューリングするかを決定し、この選択のために必要とされるデータを収集する時間。
・公平性−ユーザプロセスを異なって処理する程度の差。
コアとして機能するカーネルは、n個の他のカーネルによって囲まれている。図5は、本発明の一実施の形態に基づくシステムS1内のスターコアカーネル構成350を示している。このスターコアカーネル構成350は、KOSを有する中央ルーティングオペレーティングシステム(Central Routing Operating System)360を備え、この中央ルーティングオペレーティングシステム360は、カーネルオペレーティングシステム(kernel operating system)351〜356によって囲まれており、これらのカーネルオペレーティングシステム351〜356は、アプリケーション363の外殻によって囲まれている。各オペレーティングシステム351〜356を囲む外殻は、各オペレーティングシステム351〜356が利用可能なリソースに対応している。中央ルーティングオペレーティングシステム360は、以下の典型的なプロセス状態を取る。
図7は、共有メモリΣ1720、Σ2721、Σ3722、Σ4723と、オペレーティングシステム710〜713の環境とを含むシステム700を示している。図7に示すように、共有メモリΣ1720〜Σ4723は、まさに、UNIXオペレーティングシステムの一部であり、抽象化(abstract)は、現在、特定の規則で使用するように提供されているが、共有メモリΣ1720〜Σ4723は、本発明の実施の形態に基づく分散オペレーティングシステムの目的を果たすように、特定の方法で実装することができる。各オペレーティングシステムカーネルが専用のスケジューラとなり、これらの専用のスケジューラを有する4つのこのようなオペレーティングシステム710〜713がある場合、各スケジューラが他のスケジューラのリソースを共有することができるという方法によって、他のスケジューラと通信するように、スケジューラは設計されている。各スケジューラは、初期化(起動)のときに、他のスケジューラに知られている特定のリソースに接続する(attached)場合、その動作の任意の時点で、それが供給するリソースのカテゴリの一部でない動作を、他のスケジューラに外注することができる。
プロトコルスタックだけでなく、IPC機能も、UNIX構造とは別に設けられており、これらの両方は、既にユーティリティとして統合されている。また、これらのユーティリティは本発明にも有用である。これらのユーティリティは、幾つかのプラットフォームに亘ってではなく、特定のコンピュータシステムに組み込む現在の分散コンピューティングを除いて、クラスタ内のオペレーティングシステム間で通信を大量に行うように意図された形で構成することができる。
図8は、ネットワークコントローラを1つのリソースとして示しており、データパケット751がネットワークオペレーティングシステム(network operating system:NOS)755に送信されている。図8に示すように、カーネルスケジューラは、リソースプロセスを確保する(acquisition)フィルタを備え、カーネルスケジューラは、まず、プロセスがどこで発生すべきかを判定するために必要とされるリソースを選択する。各CPUは、汎用CPUであり、各オペレーティングシステムのカーネルは、リソースのグループ又はセットの割当に、より特化又は専用とされる。図8は、本発明に基づいて用いられる、特化又は専用とされたオペレーティングシステムの一実施の形態を示している。NOS755は、FTP、PPP、Modem、Airport、TCP/IP、NFS及びAppletalk等のプロトコルのうちの1つ以上を用いることができ、また、プロキシのオプション(Proxy options)によって、ポートを用いることができる。
I/Oオペレーティングシステムは、集中化された非同期中央OS(centralized asynchronous central OS)からのデータ読出を実行して、何時、どのようにデータを転送するかを決定するコントローラ機能を実行する。
以下の典型的なプロセス状態は、全ての種類のコンピュータシステムにおいて起こり得る。これらの状態の殆どにおいて、プロセスは、メインメモリに記憶される。
アプリケーションが開かれて、プロセスが最初に生成されたとき、プロセスは、「生成(created)」又は「新たな(new)」状態となる。このアプリケーション状態では、プロセスは、「実行可能(ready)」状態に入るのを待っている。この入力は、長期スケジューラ、すなわち入力スケジューラ、KOSスケジューラによって、承認又は遅延される。入力する間に、プロセスは、必要とされるリソースが調べられた後、実行状態に入り、あるいは、プロセスは、動作に必要とされる適切なリソースを有する他のCPUのオペレーティングシステムに切り換えられる切換状態に再設定される。
この実行可能状態は、上述した主要なプロセス状態の「実行可能」状態と同様である。
この動作状態は、上述した主要なプロセス状態の「動作」状態と同様である。
プロセスがリソース(例えばファイル、セマフォ又はデバイス)によって「ブロック」されるのではなく、(ブロックプロセスは、実行を続けることができないので)、プロセスは、現在のCPU及びオペレーティングシステムから除去されて、ブロック状態になり、プロセスが必要とするリソースが連続して利用可能な他のCPU及びオペレーティングシステムに移される。シングルCPU/シングルOSのシナリオの下では、プロセスは、そのリソースが利用可能になるまで、ブロックされたままであり、最悪の場合には、デッドロックされる。オペレーティングシステムは、ブロック状態から、ブロックされていたリソースが利用可能になったことを、プロセスに通知することができる(オペレーティングシステムそれ自体は、割込によって、リソースが利用可能になったことが通知される)。一旦、プロセスが、そのリソースが利用可能な適切なオペレーティングシステムに到着すると、プロセスは、再び「実行可能」状態に入り、この「実行可能」状態からその「実行」状態にディスパッチされ、この「実行」状態から、プロセスは、それ用に新たに利用可能になったリソースを使用することができる。
この終了状態は、上述した主要なプロセス状態の「終了」状態と同様である。
仮想メモリをサポートしているシステムでは、更に2つのプロセス状態がある。これらの状態の両方において、プロセスは、2次メモリ(通常はハードディスク)に記憶される。
このスワップアウト及び実行待ち状態は、上述した主要なプロセス状態の「スワップアウト及び実行待ち」状態と同様である。
このスワップアウト及びブロック状態は、上述した主要なプロセス状態の「スワップアウト及びブロック」状態と同様である。
本発明の実施の形態においては、通信プロトコルは、環境の下で動作するカーネル間の通信及びこれらのカーネルの下で動作するプロセス間の通信プロトコルとして定義される。この通信プロトコルにより、3つ以上のプロセスが存在することができ、アドレッシングする特定の種類の通信の外部にあるプロセスによって管理される通信によって、これらのプロセス間で同時に通信することができる。通信プロトコルは、構成アーキテクチャ(configuration architecture)の種類に応じて、異なった設計を行うことができる。
関係マネージャは、常に、環境内で動作する複数のカーネル間の関係を管理する。各カーネルによって、多くの所定のスレッドがそれらのカーネルコードを実行する役割を果たすことができるが、この要素は、関係マネージャによって実行されるタスクには関係ない。本発明の実施の形態に基づく関係マネージャによって実行されるタスクは、カーネルと、カーネル間の互いの関係とを含むものである。
全てのカーネルに常駐するスケジューラは、タスクをどのように分散させて実行するかを決定する中心的役割を果たすが、これらのスケジューラは、本発明にとっても重要であり、動作をどのような流れで実行するかを決定する中心的役割を果たす。本発明の実施の形態では、環境に割り当てられたタスクを実行する4種類以上の構成があり、これらの構成は、環境の中央コマンド構造であると考えられ、以下のように命名される。
1.階層構造(Hierarchical Structure)
本発明に基づき、環境内で複数のカーネルが同時に動作する階層構造では、ホストカーネル(host kernel)は、全ての制御の中心にあり、環境によって実行する全ての入力ジョブ又はタスクを受信する。コマンドカーネル(Command kernel)は、必要とされるリソースのタスクをスクリーニングし、特定のタスクを、このタスクが完了まで実行される適切なカーネルに割り当てる。コマンドカーネルの下には、関係マネージャがあり、関係マネージャは、コマンドカーネルと、環境内で動作する後続のカーネルとの間の関係を管理する。関係マネージャは、上述した1つと同様の制御プロトコル構造(control protocol structure)によって、他のカーネルを管理する。関係マネージャは、環境内で動作する他のカーネルのそれぞれとの間のリソース要求(resource requests)及びリソース条件を、記録して、バランスさせる。この仕事(chore)を実行するために、関係マネージャは、全てのタスク及びジョブが最初にどこに割り当てられたか、及びこれらが特定のカーネルに割り当てられた理由を理解する必要がある。階層構造の下では、環境にインストールされたリソースは、特定のカーネルに割り当てられ、例えば、プリンタは、特定のカーネルに割り当てられ、ビデオ画面(video screen)は、他のカーネルに割り当てられる。特定のI/O駆動タスク(I/O driven task)を必要とするタスクは、特定のリソースを獲得する際の遅延のために、ビデオ/オーディオ駆動タスク(video/audio driven task)に割り込まない。
ラウンドロビン構成(Round-Robin configuration)は、所定の順序でカーネルに割り当てるタスクからなる。この場合、カーネルが、タスクを実行するために必要とされるリソースを含んでいない場合、関係マネージャは、そのタスクを次のカーネルに適切に転送する役割を果たす。本発明では、ラウンドロビン構成は、多くの異なるよくある状況に適しているが、他の状況では、本発明が意図する好ましい効果(benefits)が得られないこともある。
FIFO構成の下では、各カーネルは、環境に現れる各タスクを先着順に実行する。特定のタスクがカーネルに供給され、カーネルがその所定のタスクを受け入れるために十分に解放されている場合、タスクがリソースのためにブロックされるまでは、タスクは、そのカーネルに常駐する。
スター−中央アーキテクチャは、中央コマンドカーネル(central command kernel)を環状に取り囲む複数のカーネルを有する構成として定義される。中央コマンドカーネルは、制御カーネル(controlling kernel)であり、その機能を用いて、スター構成(Star configuration)の下の他のカーネルのためのタスク要求を受信して、組織化する。スター−中央構成(Star-Center configuration)は、環境内のリソースに基づいて、下位のカーネルを星座(constellation)にグループ化する。ここで、所定のタスクが所定のリソースを用いることを必要とし、一方、他のタスクが、多くの場合、所定のタスクが所定のリソースを用いることを完了するまで、その所定のリソースによってブロックされるオペレーティングシステムについて検討する。本発明では、カーネルスレッドは、このようなボトルネックを解消する際に、特定のカーネルをコピーするように専用とされ、これに対して、他のカーネルは、それらのスレッドを適宜用いることができる。複数のオペレーティングシステムのための多くの条件のうちの1つは、専用のカーネルが、特定の種類の複数の接続された(attached)リソースを処理するそれらのコードのコピーをスレッドアウト(thread out)する能力を用いる特定のリソースを処理することができるようにすることであり、したがって、複数のカーネルは、複数のCPU上で動作するだけではなく、複数のCPUに亘るそれら自体の複数のコピーを動作させる。
リングオニオンカーネルシステムでは、複数のストリップダウンカーネル(strip-down kernel)は、オペレーティングシステムのサービス構造内で同時に機能する。オペレーティングシステムのサービス構造とは、サービスの特定のオペレーティングシステムのセットを構成する全ての補助的及び予備的ファイル(ancillary and auxiliary files)を意味する。これらのサービスは、共有することができる。このアーキテクチャ、例えばシステムコール機能及びカーネルコードの外部の他の機構の下では、設計の多様性を与え、特定の必要条件下の性能に影響を与えることができる。リングオニオンカーネルシステムの場合には、カーネルの全ては、シングルオペレーティングシステムカーネルのタスクを実行するが、これらのタスクを互いに非同期で実行し、補助的なファイル及び機能を共有するときには、これらのタスクを別々のCPU上で実行する。
従来の同期モデルにおいて維持されている基本的な前提条件の1つは、スレッドがカーネルから去る準備ができ、又はリソースがブロックされるまで、スレッドが、カーネルの占有権(exclusive rights)及びカーネルの使用権を維持すること(割込を除く)である。マルチプロセッサでは、各プロセッサは、カーネルコードを同時に実行することができるので、従来の同期モデルは、最早有効なモデルではなくなっている。複数のスレッドを用いるマルチプロセッサモデルの下では、各プロセッサが、カーネルコードのそのコピーを実行できるときには、全ての種類のデータを保護する必要がある。本発明の下では、1つの環境内に複数のカーネルがあり、各カーネルは、カーネルコードのそれら自体のコピーを実行する複数のプロセスによる動作の結果として、複数のスレッドを有するので、この種の保護は有効である。
本発明の下では、プロセッサ、したがってCPUは、他のリソースと同様に、管理されるリソースとなる。より具体的には、プロセッサマネージャは、CPUの数と、環境の下で動作するカーネル、又はカーネルスレッドの使用を管理するカーネル固有のプロセスのコピーに対するCPUの割当とを管理するプロセスである。特別なカーネルコードのコピーを実行して、特定のリソースを利用するカーネルスレッドを使用するための各要求は、プロセッサマネージャによって管理される。プロセッサの数は、プロセッサマネージャによって、分類されて(catalogued)、現在の環境内で実行中の各スレッドに割り当てられなければならない。
カーネル間通信テーブル(INTER-KERNEL COMMUNICATION TABLE)
従来のカーネルシステムの下では、カーネルは、単にロックフラグを調べ、カーネル間通信テーブルをロックするために、ロックフラグをロック位置に設定し、あるいは、カーネル間通信テーブルをアンロックするために、ロックフラグをリセットするようになっている。本発明の下では、プロセス間通信(IPC)及びカーネル間通信(IKT)は、それらに応じて管理されるシステム内のもう1つのリソースになる。これらのテーブルの複雑性(complexity)によって、システム環境の洗練度(sophistication)のレベルが決まる。本発明の下では、マルチプロセッサシステムの場合に、異なるプロセッサ上で動作するが、1つのプロセッサマネージャによって管理される2つのスレッドは、同じリソースに対する単一のロックフラグを同時に調べることができる。両方のスレッドは、ロックフラグが解除されたことが分かると、同時に特定のリソースにアクセスすることを試みる。したがって、本発明では、1つのプロセスだけがロックフラグの検査を実行し、この場合、このような検査は、リソースがプロセッサである場合には、プロセッサマネージャによって行われ、リソースがプロセッサ以外のものである場合には、リソースマネージャによって行われる。このようなマネージャの分割によって、同時のアクセスが予測できない結果となることを、ある程度防止することができる。
本発明では、スレッドマネージャは、現在のローカルカーネル(local kernel)の下で動作するプロセスとして定義され、現在のローカルカーネルの下で動作する軽量プロセス(lightweight process:LWP)及び他のプロセスに割り当てられた全てのスレッドの使用を追跡する。スレッドマネージャは、この情報を、複数のカーネル環境(Multiple Kernel Environment:MKE)の同期を支援するように動作する他の管理システムに報告する。MKEが上述した5つの構成のうちの1つに組織化された場合、スレッドマネージャの報告は、この特定の環境の必要条件を満たすように変更することができる。スレッドマネージャにとって、重要なことは、例えば、特定のシステムの下で、所定のリソースをより正確に追跡するために、割り当てられたスレッドの数を報告することである。リソースの報告は、リソースマネージャの役割であり、したがって、リソースマネージャは、この種類の情報を提供するスレッドマネージャに依存する。
本発明では、リソースマネージャは、環境内に存在すると考えられるリソースのマネージャとして定義される。例えば、リソースは、あらゆるオペレーティングシステム環境に不可欠なコンポーネントであると考えられ、したがって、複数のカーネルが常駐する又は常駐できるシステムの下では、このステートメント(statement)は、重要な意味を持つ。リソースマネージャは、ローカルカーネルレベルに常駐するリソースを管理し、あるタスクが特定のリソースを要求する毎に、これらの要求は、リソースマネージャを介して行われ、特定のカーネル上では利用不可能なリソースに対する要求が行われた場合、リソースマネージャは、リソースを必要とするタスクと、特定のリソースを有するカーネルとの間に関係を築くために、関係マネージャに連絡する。
本発明では、リソース割当マネージャは、特定のリソースを用いて1つのカーネル上で開始するが、他のカーネルに接続(attached)される可能性があるリソースを必要とする開始タスクを有するプロセス間に割り当てられた全てのリソースの記録を行う。このような状況では、リソースマネージャは、特定のリソースを見つけ、あるいは環境内の利用可能な全てのリソースの目録を作る(inventory)ためには、リソース割当マネージャと連絡する必要がある。このような場合、カーネル間の全てのリソース割当を管理するリソース割当マネージャは、必要な情報をリソースマネージャに供給する。
図14〜図23は、本発明の実施の形態のより詳細な具体例を示している。本発明の一実施の形態では、KOSは、中央ではなく、個々のオペレーティングシステム内で実行される。プロセスは、情報を、例えば共有メモリを用いて交換して、何時リソースが利用可能か、又は何時リソースが利用可能になるかを他のプロセスに通知する。一具体例として、図14は、リソースR1に関する情報を、共有メモリ1015を用いて交換する2つのプロセス1001、1010を示している。共有メモリ1015は、プロセス1010が待っているリソースR1が、今利用可能になったことを示す情報を含んでいる。このとき、プロセス1010は、リソースR1を、例えばリソースR1に対するコールを生成することによって要求することができる。
Claims (26)
- 複数のリソースと、
コンピュータシステム上で実行されるプロセスに対するリソースの割当を調整するカーネルスケジューラをそれぞれ含む複数のオペレーティングシステムを記憶したメモリとを備えるコンピュータシステム。 - 上記複数のオペレーティングシステムのうちの異なる1つをそれぞれ実行する複数の中央演算処理装置を更に備える請求項1記載のコンピュータシステム。
- 上記複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の2つ以上を含むことを特徴とする請求項1記載のコンピュータシステム。
- 上記複数のカーネルスケジューラは、リソース関連情報を、通信プロトコルを用いて共有することを特徴とする請求項1記載のコンピュータシステム。
- 上記通信プロトコルは、共有メモリにアクセスすることを特徴とする請求項4記載のコンピュータシステム。
- 上記通信プロトコルは、プロセス間通信又はプロトコルスタックを含むことを特徴とする請求項4記載のコンピュータシステム。
- 上記通信プロトコルは、伝送制御プロトコル/インターネットプロトコルを含むことを特徴とする請求項4記載のコンピュータシステム。
- 上記通信プロトコルは、セマフォのアクセス、パイプ、信号、メッセージキュー、データに対するポインタ及びファイル記述子を含むことを特徴とする請求項4記載のコンピュータシステム。
- 上記複数のプロセスは、互いに通信する少なくとも3つのプロセスからなることを特徴とする請求項4記載のコンピュータシステム。
- 上記複数のカーネルスケジューラのそれぞれは、上記リソースの割当を調整する関係マネージャを備えることを特徴とする請求項1記載のコンピュータシステム。
- 上記複数の関係マネージャのそれぞれは、上記複数のリソースのうちの1つ以上に関するリソース情報を判定するリソースマネージャを備えることを特徴とする請求項10記載のコンピュータシステム。
- 上記リソース情報は、リソースが利用可能になるまでの見積時間を含むことを特徴とする請求項11記載のコンピュータシステム。
- 1つのカーネルスケジューラと、複数のリソースにアクセスする複数のオペレーティングシステムカーネルとを記憶したメモリを備え、
上記カーネルスケジューラは、上記複数のリソースのうちの1つリソースを要求するプロセスを、上記複数のオペレーティングシステムカーネルのうちの対応する1つに割り当てることを特徴とするコンピュータシステム。 - それぞれが上記複数のオペレーティングシステムカーネルのうちの対応する1つを実行する複数のプロセッサを更に備える請求項13記載のコンピュータシステム。
- 上記カーネルスケジューラは、上記複数のオペレーティングシステムカーネル上のプロセスを、上記複数のプロセッサの負荷に基づいてスケジューリングすることを特徴とする請求項14記載のコンピュータシステム。
- 上記複数のリソースは、キーボードコントローラ、ビデオコントローラ、オーディオコントローラ、ネットワークコントローラ、ディスクコントローラ、ユニバーサルシリアルバスコントローラ及びプリンタのうちの任意の2つ以上を含むことを特徴とする請求項13記載のコンピュータシステム。
- リソースの要求を、上記複数のオペレーティングシステムカーネルのうちの1つ以上に照合するプロセステーブルを更に備える請求項13記載のコンピュータシステム。
- 上記複数のオペレーティングシステムカーネルのうちのペア間の通信チャンネルを更に備える請求項13記載のコンピュータシステム。
- 上記複数のオペレーティングシステムカーネルは、プロセッサの負荷と、リソースの利用可能性と、リソースが利用可能になるまでの見積時間とに関する情報を交換することを特徴とする請求項13記載のコンピュータシステム。
- それぞれがオペレーティングシステムカーネルを実行し、1つ以上のリソースにアクセスする複数のプロセッサと、
リソースにアクセスできる複数のオペレーティングシステムカーネルのうちの1つに、リソースを要求するプロセスを照合し、該プロセスをディスパッチするようにプログラムされた割当モジュールとを備えるカーネルスケジューリングシステム。 - 上記複数のプロセッサのそれぞれは、対応するプロセッサスケジューラによって制御されることを特徴とする請求項20記載のカーネルスケジューリングシステム。
- リソースをオペレーティングシステムカーネルに割り当てるリソース割当方法において、
複数のオペレーティングシステムカーネルの中から1つのオペレーティングシステムカーネルを、そのリソースにアクセスする能力に基づいて選択するステップと、
上記選択されたオペレーティングシステムカーネルにプロセスを割り当てるステップとを有するリソース割当方法。 - 上記複数のオペレーティングシステムカーネルの全ては、単一メモリ内で実行されることを特徴とする請求項22記載のリソース割当方法。
- シングルコンピュータシステムのメモリ上の第1のオペレーティングシステムと第2のオペレーティングシステム間でプロセス実行を共有するプロセス実行共有方法において、
上記メモリ内でプロセスを、上記第1のオペレーティングシステムの制御の下に実行するステップと、
上記プロセスの制御を、上記第2のオペレーティングシステムに上記メモリ内で移して、該メモリ内で該プロセスを、該第2のオペレーティングシステムの制御の下に実行するステップとを有するプロセス実行共有方法。 - 上記第1のオペレーティングシステムと上記第2のオペレーティングシステムの制御の下におけるプロセスの実行の両方では、単一のリソースにアクセスすることを特徴とする請求項24記載のプロセス実行共有方法。
- 上記第1のオペレーティングシステムと上記第2のオペレーティングシステム間で、共有メモリ、プロセス間通信及びセマフォのうちの1つを用いて、プロセス情報を交換するステップを更に有する請求項25記載のプロセス実行共有方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008285653A JP5676845B2 (ja) | 2008-11-06 | 2008-11-06 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008285653A JP5676845B2 (ja) | 2008-11-06 | 2008-11-06 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014204814A Division JP5891284B2 (ja) | 2014-10-03 | 2014-10-03 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2010113524A true JP2010113524A (ja) | 2010-05-20 |
JP5676845B2 JP5676845B2 (ja) | 2015-02-25 |
Family
ID=42302038
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008285653A Expired - Fee Related JP5676845B2 (ja) | 2008-11-06 | 2008-11-06 | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5676845B2 (ja) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2012164006A (ja) * | 2011-02-03 | 2012-08-30 | Fujitsu Ltd | クロック周波数制御プログラム、クロック周波数制御装置 |
US8615165B2 (en) | 2010-10-06 | 2013-12-24 | Sony Corporation | Video-recording and replaying apparatus, I/O scheduling method, and program |
WO2014118870A1 (ja) * | 2013-01-29 | 2014-08-07 | 株式会社日立製作所 | 計算機および計算機の制御方法 |
JP2015022763A (ja) * | 2013-07-18 | 2015-02-02 | ポハン工科大学校産学協力団Postech Academy−Industry Foundation | オペレ−ティングシステム構成装置及び方法 |
US9244733B2 (en) | 2012-02-06 | 2016-01-26 | Samsung Electronics Co., Ltd. | Apparatus and method for scheduling kernel execution order |
CN114296631A (zh) * | 2020-10-07 | 2022-04-08 | 爱思开海力士有限公司 | 存储器系统及其操作方法 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0460843A (ja) * | 1990-06-29 | 1992-02-26 | Hitachi Ltd | マルチプロセッサシステムにおけるタスクスケジュール方式 |
JPH05204678A (ja) * | 1992-01-29 | 1993-08-13 | Nec Corp | オンライントランザクションデータ処理システム |
JPH1027109A (ja) * | 1996-07-10 | 1998-01-27 | Nippon Telegr & Teleph Corp <Ntt> | 資源割当て方法 |
JPH11249916A (ja) * | 1998-03-03 | 1999-09-17 | Fujitsu Ltd | メモリ管理装置および記録媒体 |
JP2008097356A (ja) * | 2006-10-12 | 2008-04-24 | Canon Inc | デジタル複合機及びその制御方法、プログラム並びに記憶媒体 |
JP2008262419A (ja) * | 2007-04-12 | 2008-10-30 | Toyota Motor Corp | 情報処理装置、オペレーティングシステム選択方法、プログラム。 |
-
2008
- 2008-11-06 JP JP2008285653A patent/JP5676845B2/ja not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0460843A (ja) * | 1990-06-29 | 1992-02-26 | Hitachi Ltd | マルチプロセッサシステムにおけるタスクスケジュール方式 |
JPH05204678A (ja) * | 1992-01-29 | 1993-08-13 | Nec Corp | オンライントランザクションデータ処理システム |
JPH1027109A (ja) * | 1996-07-10 | 1998-01-27 | Nippon Telegr & Teleph Corp <Ntt> | 資源割当て方法 |
JPH11249916A (ja) * | 1998-03-03 | 1999-09-17 | Fujitsu Ltd | メモリ管理装置および記録媒体 |
JP2008097356A (ja) * | 2006-10-12 | 2008-04-24 | Canon Inc | デジタル複合機及びその制御方法、プログラム並びに記憶媒体 |
JP2008262419A (ja) * | 2007-04-12 | 2008-10-30 | Toyota Motor Corp | 情報処理装置、オペレーティングシステム選択方法、プログラム。 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8615165B2 (en) | 2010-10-06 | 2013-12-24 | Sony Corporation | Video-recording and replaying apparatus, I/O scheduling method, and program |
JP2012164006A (ja) * | 2011-02-03 | 2012-08-30 | Fujitsu Ltd | クロック周波数制御プログラム、クロック周波数制御装置 |
US9244733B2 (en) | 2012-02-06 | 2016-01-26 | Samsung Electronics Co., Ltd. | Apparatus and method for scheduling kernel execution order |
WO2014118870A1 (ja) * | 2013-01-29 | 2014-08-07 | 株式会社日立製作所 | 計算機および計算機の制御方法 |
JP2015022763A (ja) * | 2013-07-18 | 2015-02-02 | ポハン工科大学校産学協力団Postech Academy−Industry Foundation | オペレ−ティングシステム構成装置及び方法 |
CN114296631A (zh) * | 2020-10-07 | 2022-04-08 | 爱思开海力士有限公司 | 存储器系统及其操作方法 |
CN114296631B (zh) * | 2020-10-07 | 2024-01-30 | 爱思开海力士有限公司 | 存储器系统及其操作方法 |
Also Published As
Publication number | Publication date |
---|---|
JP5676845B2 (ja) | 2015-02-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2704269C (en) | Uniform synchronization between multiple kernels running on single computer systems | |
EP2799990B1 (en) | Dynamic virtual machine sizing | |
JP5324934B2 (ja) | 情報処理装置および情報処理方法 | |
Black | Scheduling support for concurrency and parallelism in the Mach operating system | |
KR101258502B1 (ko) | 멀티코어 아키텍처 내의 리소스 관리 | |
JP5891284B2 (ja) | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 | |
JP3877527B2 (ja) | マルチストリーミングプロセッサ向けの優先順位付き命令スケジューリング | |
US8572626B2 (en) | Symmetric multi-processor system | |
US20060130062A1 (en) | Scheduling threads in a multi-threaded computer | |
JP5676845B2 (ja) | コンピュータシステム、カーネルスケジューリングシステム、リソース割当方法及びプロセス実行共有方法 | |
US9417920B2 (en) | Method and apparatus for dynamic resource partition in simultaneous multi-thread microprocessor | |
Cheng et al. | vScale: Automatic and efficient processor scaling for SMP virtual machines | |
JP2013506179A (ja) | 命令スレッドを組み合わせた実行の管理システムおよび管理方法 | |
JP2002063148A (ja) | 多重プロセッサ・システム | |
US20080229319A1 (en) | Global Resource Allocation Control | |
US7103631B1 (en) | Symmetric multi-processor system | |
Puthoor et al. | Oversubscribed command queues in GPUs | |
Yu et al. | Colab: a collaborative multi-factor scheduler for asymmetric multicore processors | |
US8539491B1 (en) | Thread scheduling in chip multithreading processors | |
Li et al. | Rosgm: A real-time gpu management framework with plug-in policies for ros 2 | |
Sodan | Loosely coordinated coscheduling in the context of other approaches for dynamic job scheduling: a survey | |
Parikh et al. | Performance parameters of RTOSs; comparison of open source RTOSs and benchmarking techniques | |
Walters et al. | Enabling interactive jobs in virtualized data centers | |
CA2316643C (en) | Fair assignment of processing resources to queued requests | |
Wang et al. | Amcilk: A framework for multiprogrammed parallel workloads |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20111012 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130212 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20130513 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20130516 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130612 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20131029 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20140128 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20140603 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20141003 |
|
A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20141010 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20141202 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20141226 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5676845 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |