Linux スケジューラーのシミュレーション

LinSched を使用してユーザー空間で Linux スケジューラーをシミュレートする

スケジューリングは、Linux カーネルの最も複雑で、最も興味深い側面の 1 つです。シングル・コアのマシンにも、クアッド・コアのサーバーにも適切な振る舞いを提供するスケジューラーを開発するのは簡単なことではありません。けれども幸いなことに、Linux スケジューラー・シミュレーターである LinSched は (スケジューラーのプロトタイプを作成するために) ユーザー空間で Linux スケジューラーをホストしながら、任意のハードウェア・ターゲットをモデル化して各種のトポロジーでスケジューラーを検証します。この記事を読んで、LinSched の概要、そして Linux のスケジューラーを試す方法を学んでください。

M. Tim Jones (mtj@mtjones.com), Platform Architect, Intel

author photo - M. Tim JonesM. Tim Jones は組み込みソフトウェアのエンジニアであり、『Artificial Intelligence: A Systems Approach』、『GNU/Linux Application Programming』(現在、第 2 版です) や『AI Application Programming』(こちらも現在、第 2 版です)、それに『BSD Sockets Programming from a Multilanguage Perspective』などの著者でもあります。技術的な経歴は静止軌道衛星用のカーネル開発から、組み込みシステム・アーキテクチャーやネットワーク・プロトコル開発まで、広範にわたっています。彼は Intel に勤務していて、コロラド州ロングモン在住です。



2011年 2月 23日

Linux でのタスクのスケジューリングは、複雑な作業です。Linux は非常に多彩なプロセッサー・トポロジー (シングル・コア、マルチコア、マルチコア/マルチスレッドなど) をベースに、エンタープライズ・サーバーやクライアント・デスクトップ、さらには組み込みデバイスに至るまでの多種多様な使用モデルで動作します。それにも関わらず、Linux にはスケジューリング・ポリシーが少ししかないのは、まったく驚くべきことです。

さらに事態を悪化させているのは、スケジューラーがカーネルの奥深くにあることです。そのため、簡単には Linux のスケジューリング・ポリシーの有効性を測定することができません。トレースなどのイントロスペクションを追加すると、それによってスケジューラーの振る舞いが変更されて、欠陥や非効率性が見えなくなる可能性があります。さらに、特定のワークロードを各種のプロセッサー・トポロジーで検証するスケジューリング・シナリオをセットアップするとなると、悪夢のような作業となるのは必至です。

幸い、この問題の解決に役立つプロジェクトがあります。その 1 つは、LinSched (ユーザー空間の Linux スケジューラー・シミュレーター) です。

LinSched の概要

LinSched は、ユーザー空間で実行される Linux スケジューラー・シミュレーターです。LinSched は Linux スケジューラー・サブシステムを切り離し、そのサブシステムを中心としたカーネル環境を構築します。このカーネル環境はユーザー空間内で LinSched を実行できるだけの十分な環境です。LinSched を操作するために作成された API を使用すると、スケジューリングのワークロードの検証を行ったり、スケジューラーの振る舞いを理解するのに十分な関連データの収集を行ったりする上で必要なトリガーを与えることができます (LinSched に関しては、この少し後で、その全体のアーキテクチャーを探ります)。

スケジューラーをユーザー空間に取り込めば、スケジューラーがクラッシュしてもマシン全体の機能停止に至ることがないため、スケジューラーを気軽に実行できるようになります。また、スケジューラーに関するデータの収集も単純化されます。スケジューラーがユーザー空間にあれば、ローカル・ファイルシステム内で簡単かつ効率的にデータを収集し、保管できるからです。

別のシミュレーション手法としては、仮想化を使用することもできますが、LinSched のほうが単純さと効率性の点で勝っています (これは、LinSched の場合、別のカーネルをブートする必要がないからです)。ユーザー空間のプロセスであれば、スケジューラーの動作をさらに掘り下げて理解するために GDB (GNU Debugger) などのデバッガーを接続するのも簡単です。


LinSched の起源

LinSched は元々ノースカロライナ大学で (IBM と Intel から助成金を受けて) 開発されましたが、最近になって、Google がスケジューリング・ポリシーを検証するために復活させました。これは興味深い動向で、今後の傾向を表しているかもしれません。Linux はスケジューリング・クラスを数多くサポートしており、ワークロードが多数存在する場合のスケジューリングに十分対処できることは確かですが、あるハードウェア・トポロジーでの特定のワークロードにとっては、理想的ではないかもしれません。Google は特定のタスク (例えば、MapReduce) を行う複数の同一マシンからなる大規模なクラスターに投資していることから、スケジュールがその特定のタスクと環境に合わせて調整されるのは当然です。Google が LinSched を使用することで、Linux にも CFS (Completely Fair Scheduler) の機能強化というメリットがもたらされます。これには、タスク間で負荷にかなりの違いがある場合の帯域幅のプロビジョニングやロード・バランシングが含まれます。


LinSched のアーキテクチャー

LinSched は、ユーザー空間で実行されるスケジューラー・シミュレーターというだけではありません。LinSched は Linux スケジューラーをユーザー空間へマイグレーションしたものに、必要なコンポーネントの最小限のエミュレーションを追加したものであることから、カーネル外部でのスケジューラーの実行が可能になります。LinSched のソースは、実際にはラッパーとシミュレーション・エンジン用に ./linsched という新しいサブディレクトリーが追加された Linux ディストリビューション (現在の最新版は 2.6.35) です。LinSched のシミュレーションには Linux 内部の Linux スケジューラー・サブシステムが使用されるため、変更を行うのも、その変更をカーネルに統合するのも至って簡単です。

図 1 に、LinSched のアーキテクチャー全体を示します。一番下にあるのは、ホスト・オペレーティング・システムです。LinSched は、多数のコンポーネント (Linux カーネル自体の一部を含む) から構成されたユーザー空間のアプリケーションです。

図 1. LinSched スケジューラー・シミュレーターのアーキテクチャー
LinSchedのアーキテクチャーを示す図

環境モジュール (Environment module) は、Linux カーネルを抽象化するためのモジュールです (フラグを使用してシミュレーション・モードでのコンパイルをサポートします)。環境モジュールの上にあるシミュレーション・エンジン (Simulation engine) は、環境を構成してシミュレーションを行うときに使用する API を拡張します。シミュレーション・エンジン API が提供する初期化関数は、プロセッサー・トポロジー、タスクを作成するための関数、コールバック (タスクがスケジュールされたときのコールバックなど)、そしてある一定のティック数でシミュレーションを行う run 関数 (この関数が、スケジューリングの決定を行う Linux 内部関数 schedule() を呼び出します) も定義します。

シミュレーション・エンジンの上には、スクリプト環境 (実際のシミュレーションを行うコード) があります。これは単一のスクリプトにすることもできますが、この後の例でわかるように、既存のスクリプト環境に手を加えてテスト・シナリオを追加することが最も簡単な使用方法となります。

LinSched の基本アーキテクチャーは極めて単純です。まず始めに、LinSched をインストールする方法を説明します。その後、拡張 API をいくつか取り上げて、これらの API をシミュレーションで使用する方法を検討します。


LinSched のインストール

最近、LinSched はカーネル 2.6.35 をサポートするように更新されました。最新の LinSched パッケージを入手するには、git を通じて入手する方法、あるいはこのプロジェクトの Web ページ (「参考文献」を参照) を通じて入手する方法があります。git を使ってディストリビューションを取得する場合は、以下のようにリポジトリーを複製してください。

$ git clone git://google3-2.osuosl.org/linsched/2.6.35.git

いずれの方法を使用するにしても、ディストリビューションが含まれる 2.6.35/ というサブディレクトリーが作成されます。この LinSched サブディレクトリーでは、以下のコマンドを実行して簡単なテストを行うことができます。

$ make run_all_tests

このコマンドによって、各種プロセッサー・トポロジーで多数のスケジューラー・テストが実行されて、テスト結果が出力されます。


LinSched の API

LinSched によるシミュレーションを実行するには、スクリプトを作成してひととおりの初期化を行い、目的のシナリオをセットアップします。初期化は、LinSched API を呼び出すことで行われます。このセクションでは、いくつかの重要な API 関数について見ていきます (後で、それぞれの使用例を記載します)。以降の説明は、すべての API を網羅するわけではありません。API を詳細に調べるには、./linsched 内のソース・ファイルを参照してください。

シミュレーションを実行する前に、シミュレーターを初期化する必要があります。それには、linsched_init を呼び出します。この関数は、引数としてシミュレーション対象のプロセッサー・トポロジーを取り、内部でシミュレーター環境を構成して、ユーザー空間の Linux カーネルを起動します。

void linsched_init( struct linsched_topology *topo );

linux_linsched.h に定義されたトポロジー構造は、プロセッサーの数と、プロセッサー間の関係を定義します (物理パッケージとノード距離のマップにマッピングします)。シングル・プロセッサー・パッケージは TOPO_UNIPROCESSOR で、4 ソケットのクアッド・コア・プロセッサー・トポロジーは TOPO_QUAD_CPU_QUAD_SOCKET で指定することができます。

LinSched 内のタスクはシミュレートされたエンティティーですが、LinSched ではユーザーが多数のタスク・シナリオの作成を制御できるようになっています。その際に最も役立つ関数の 1 つは、ビジー/スリープ構成に従うタスクをいくつも作成する関数です。呼び出し側はこの関数に対して、作成するタスクの数 (count)、これらのタスクが実行可能なプロセッサーのマスク (mask)、スリープのティック数 (sleep)、ビジーのティック数 (run) を渡します。

void create_tasks( unsigned int count, unsigned long mask, int sleep, int run );

より具体的なタスク・シナリオを作成できるように、他にもタスク作成用の API 関数がいくつか用意されています (リスト 1 を参照)。これらの関数では、優先度または nice 値を指定して、標準タスク、バッチ・タスク、FIFO (ファーストイン・ファーストアウト) によるリアルタイム・タスク、ラウンドロビンによるリアルタイム・タスクを作成することができます。linsched_create_normal_task で標準タスクを作成すると、スケジューリング・ポリシーが SCHED_NORMAL に設定されます。linsched_create_batch_task (バッチ・タスク)、linsched_create_RTfifo_task (FIFO によるリアルタイム・タスク)、linsched_create_RTrr_task (ラウンドロビンによるリアルタイム・タスク) ではスケジューリング・ポリシーが、それぞれ SCHED_BATCHSCHED_FIFOSCHED_RR に設定されます。ユーザーは、このようにタスク構造を指定して特定のタスクの振る舞いを制御することも、linsched_create_sleep_run を使用してスリープ/ビジーのティック数を任意に設定した汎用的なタスクを作成することもできます。これらのタスクのそれぞれを調べるには、linux_linsched.c を参照してください。

リスト 1. LinSched のタスク作成用 API 関数
int linsched_create_normal_task( struct task_data* td, int niceval );
void linsched_create_batch_task( struct task_data* td, int niceval );
void linsched_create_RTfifo_task( struct task_data* td, int prio );
void linsched_create_RTrr_task( struct task_data* td, int prio );
struct task_data *linsched_create_sleep_run( int sleep, int busy );

API を使用して、複数のタスク・グループを作成し、これらのグループにタスクを追加し、タスク・スケジューリングのためのプロセッサー・シェアをそれぞれのグループに割り当てることもできます。リスト 2 に、これらの関数 (linux_linsched.c に含まれています) を記載します。

Listing 2. LinSched task group and group shares API functions
int linsched_create_task_group( int parent_group_id );
void linsched_set_task_group_shares( int group_id, unsigned long shares );
int linsched_add_task_to_group( int task_id, int group_id );

シミュレーションを開始するには、linsched_run_sim を呼び出します。この呼び出しが唯一の引数として受け入れるのは、実行するティック数のみです。この関数では各ティックで、スケジューリングの決定が行われます。シミュレーションが完了すると、hrtimer.c に含まれている関数がリターンを実行します。

void linsched_run_sim( int sim_ticks );

最後に、シミュレーションの結果を表示するには、リスト 3 に記載する呼び出しを使用します。これらの呼び出しにより、個々のタスクの統計、グループの統計がそれぞれ出力されます。

リスト 3. シミュレーション統計を出力する LinSched の関数
void linsched_print_task_stats( void );
void linsched_print_group_stats( void );

さらに詳しく分析する場合には、以下の関数を使用してプロセッサー ID を基準にタスクを取得することができます。

struct task_struct *linsched_get_task( int task_id );

タスク構造を使用することで、タスクの合計実行時間 (task_exec_time(task) を使用)、実行していなかった時間 (task->sched_info.run_delay)、スケジューラーがタスクを呼び出した回数 (task->sched_info.pcount) を調べることができます。

以上の短いリストからわかるように、LinSched はスケジューリング・シナリオの作成に役立つ API を提供しています。これらの関数は繰り返し実行することもできるので、例えばシナリオの開始時と終了時に新しいタスクを追加して、シミュレーションが引き続き別の linsched_run_sim を呼び出すようにすることも可能です。この機能によって、繰り返しも可能な動的スケジューリング・シナリオを作成することができます。


LinSched のテスト

LinSched シミュレーション・エンジンの API について説明したところで、今度はこの API の使用例を見ていきます。この例 (リスト 4 を参照) では、新しいシナリオを追加するために LinSched の new_test フレームワークを使用しました。このフレームワークでは、使用するトポロジーが 2 番目の引数として渡されます。topo_db は、サポートしている各種トポロジーを提供しています (フレームワークは引数で指定されたトポロジーを使って、11 のタスクすべてを実行します)。トポロジーを指定して linsched_init を呼び出すと、指定されたプロセッサー・トポロジーに応じて環境が初期化されます。環境が初期化されたら、3 つのカテゴリーの 11 のタスクを作成します。単純な create_tasks 関数を使って作成する最初の 5 つのタスクは、プロセッサー・バウンドのタスク (90% の時間がビジー状態で、10% がスリープ状態のタスク) をエミュレートします。次に作成するのは、5 つの I/O バウンドのタスク (10% の時間がビジー状態で、90% がスリープ状態) です。そして最後にもう 1 つ、linsched_create_RTrr_task を使用して、優先度が 90 のリアルタイム・タスク (100% の時間がビジー状態) を作成します。タスクを作成したら、linssched_run_sim を呼び出してシミュレーターを起動し、linsched_print_task_stats によって結果を出力します。

注: この例では、標準 CFS を使用します (linsched_run_sim を介した schedule() によって呼び出します)。

リスト 4. LinSched のサンプル・スクリプト
void new_test(int argc, char **argv)
{
  int count, mask;
  struct linsched_topology topo;
  int type = parse_topology(argv[2]);

  topo = topo_db[type];

  // Allow all tasks to use any processor.
  mask = (1 << count) - 1;

  // Initialize the topology as provided by the script interpreter
linsched_init(&topo);

  // Create five processor-bound tasks (sleep 10, busy 90)
create_tasks(5, mask, 10, 90);

  // Create five I/O-bound tasks (sleep 90, busy 10)
create_tasks(5, mask, 90, 10);

  // Create a busy real-time round-robin task with a priority of 90
linsched_create_RTrr_task( linsched_create_sleep_run(0,100), 90 );

  // Run the simulation
linsched_run_sim(TEST_TICKS);

  // Emit the task statistics
linsched_print_task_stats();

  return;
}

このシナリオを実行すると、その実行におけるタスクごとの出力は多様な結果になります。例えばリスト 5 は、ユニプロセッサー・トポロジーでシナリオ (リスト 4) を実行した場合の出力です。この出力には、タスク ID の番号が付けられたタスクの一覧が表示され、タスクの合計実行時間 (ティック数)、実行待機時間、そして呼び出された回数が示されています。これらのタスクは、API を使って終了させなければ、永遠に実行し続けることに注意してください。

このシナリオによると、最初の 5 つのタスクはビジーなタスクで、10% の時間だけスリープ状態になります。次の 5 つのタスクは、ほとんどの時間、スリープ状態を維持し、ビジー状態になるのは 10% の時間だけです。最後のリアルタイム・タスクは 100% の時間、ビジー状態です。リスト 5 に示されているように、リアルタイム・タスクはこのシングル・プロセッサーのほとんどの時間を占有し、61 回しか呼び出されていません。それに対し、ビジー・タスクおよび非ビジー・タスクは、遥かに少ないプロセッサー時間のために、約 3 倍もの回数呼び出されています。またもう 1 つ注目する点として、スケジューラーはビジー・タスクと非ビジー・タスクに対して公平であり、ほぼ均等なプロセッサー・アクセスを割り当てています。

リスト 5. ユニプロセッサー・トポロジーでのテストのスケジューリング
Task id =  1, exec_time =   305000000, run_delay = 59659000000, pcount = 156
Task id =  2, exec_time =   302000000, run_delay = 58680000000, pcount = 154
Task id =  3, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  4, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  5, exec_time =   304000000, run_delay = 58708000000, pcount = 155
Task id =  6, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  7, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  8, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id =  9, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id = 10, exec_time =   296000000, run_delay = 56118000000, pcount = 177
Task id = 11, exec_time = 57001000000, run_delay =  2998000000, pcount = 61

今度はリスト 4 と同じテストを、4 ソケットのクアッド・コア・トポロジー (16 の論理プロセッサー) で実行した場合を見ていきます。タスクごとに 1 つの論理プロセッサーを使用できるため、テスト時間は同じでも、プロセッサー時間の割り当ては大幅に多くなります。ビジー・タスクと非ビジー・タスクの呼び出し回数は同じですが、非ビジー・タスクに割り当てられた実行時間はビジー・タスクの 10% に過ぎません。この違いは、スリープ/ビジー構成による結果です (ビジー・タスクの実行時間は 90 ティックである一方、非ビジー・タスクの実行時間は 10 ティックとなっています)。さらに興味深い点は、リアルタイム・タスクは 1 度呼び出されると、テスト期間全体にわたって実行が継続されることです (リアルタイム・タスクはスリープ状態にならないため、プロセッサーで再スケジューリングされなかったことがその理由です)。リスト 6 に、このテスト結果を記載します。

リスト 6. クアッド・コア 4 ソケットでのテストのスケジューリング
Task id =  1, exec_time = 54000000000, run_delay = 0, pcount = 601
Task id =  2, exec_time = 54000156250, run_delay = 0, pcount = 600
Task id =  3, exec_time = 54000281250, run_delay = 0, pcount = 600
Task id =  4, exec_time = 54000406250, run_delay = 0, pcount = 600
Task id =  5, exec_time = 54000031250, run_delay = 0, pcount = 600
Task id =  6, exec_time =  6000187500, run_delay = 0, pcount = 600
Task id =  7, exec_time =  6000312500, run_delay = 0, pcount = 600
Task id =  8, exec_time =  6000437500, run_delay = 0, pcount = 600
Task id =  9, exec_time =  6000062500, run_delay = 0, pcount = 600
Task id = 10, exec_time =  6000218750, run_delay = 0, pcount = 600
Task id = 11, exec_time = 59999343750, run_delay = 0, pcount = 1

LinSched によって出力されるデータは、可視化することも可能です。そこでもう 1 つの例として、出力をグラフ表示してみます。リスト 7 に記載する例では、-20 から 19 までの nice 値を設定した 40 のタスクを作成します。タスクの nice 値によって、タスクの優先度が変更されることを思い出してください (この例では、-20 が最高の優先度で、20 が最低の優先度です)。標準タスクのスケジューリングの場合、タスクにはその nice 値に比例したプロセッサー時間が割り当てられます。

リスト 7. 標準タスクのスケジューリングでの nice 値の効果を説明するデモ
void new_test(int argc, char **argv)
{
  int count, mask, i;
  struct linsched_topology topo;
  int type = parse_topology(argv[2]);

  topo = topo_db[type];

  // Allow all tasks to use any processor.
  mask = (1 << count) - 1;

  // Initialize the topology as provided by the script interpreter
linsched_init(&topo);

  for (i = 0 ; i < 40 ; i++) {
linsched_create_normal_task( linsched_create_sleep_run(0,100), i-20 );
  }

  // Run the simulation
linsched_run_sim(TEST_TICKS*10);

  // Emit the task statistics
linsched_print_task_stats();

  return;
}

このアプリケーションの実行結果は、図 2 のグラフ (ユニプロセッサー・トポロジーの場合) となります。このように、優先度の高いタスクには、プロセッサー時間のほとんどが割り当てられる一方、優先度の低いタスクに割り当てられるプロセッサー時間は大幅に少なく、指数曲線的に減少しています。最大優先度のタスク (nice 値 -20) には 1200 億ティックが割り当てられましたが、最低優先度のタスク (nice 値 19) に割り当てられたのは 2100 万ティックでした。

図 2. リスト 7 の各タスクの実行時間をプロットしたグラフ
リスト 7 の各タスクの実行時間をプロットしたグラフ

スケジューリングを可視化するその他のオプション

LinSched はユーザー空間でスケジューラーをシミュレートできるという点で価値あるツールですが、カーネルのスケジューリングやその他のアクティビティーを可視化するためのツールは他にもあります。例えば、LTT (Linux Trace Toolkit) は、システム・イベントの詳細な目録を作成して Linux カーネルの内部で行われている処理を可視化します。LTT プロジェクトは進化して、現在は LTTng (LTT next generation) になっています。LTTng は、カーネルで行われている処理をグラフ (またはテキスト) に可視化するユーザー空間のツールです。また、このツールはユーザー空間をトレースするために使用することも、カーネル空間およびユーザー空間からのトレースを集約して複合トレースを行うために使用することもできます。詳細については、「参考文献」を参照してください。


さらに詳しく調べてください

この短い記事からでも、ユーザー空間で Linux スケジューラーをシミュレートすることの価値を理解できたはずです。LinSched を使った取り組みによって、ユーザー空間のシミュレーションと実際のカーネル・ベースのスケジューリングとが密接に関連することが明らかになっています。つまり、こうした手法は本番環境でのスケジューラーの振る舞いを予測するのに役立ちます。また、LinSched が使用する手法も興味深い点です。LinSched では、ユーザー空間でスケジューリングを行えるようにするための新しいフレームワークを作成する代わりに、Linux カーネル・コードそのものを (プラットフォームをエミュレートするためのラッパーとともに) 使用します。つまり、スケジューラーがユーザー空間で検証されれば、あとはごく簡単に、このスケジューラーをカーネルにマイグレーションして使用できるというわけです。

LinSched についての詳細、およびスケジューラーのシミュレーションと可視化に役立つその他のツールや技術については、「参考文献」を調べてください。

参考文献

学ぶために

  • Linux スケジューラー・シミュレーターである LinSched は、スケジューリング・サブシステムをホストするユーザー空間のアプリケーションです。このツールは、Linux スケジューリグ・ポリシーの振る舞いを分析するのに非常に役立ちます。github (LinSched の git リポジトリー) で最新のソースをオンラインで見ることもできます。
  • LinSched について書かれた短いホワイトペーパー、「LinSched: The Linux Scheduler Simulator」は、このツールの詳細を学ぶ絶好の方法となります。この文書では、LinSched の概要に加え、このツールを使用したワークロードのシミュレーションの例を説明しています。
  • 2.6 Linux カーネルの開発初期に、既存の (そして複雑な) スケジューラーに代わる新しいスケジューラーが導入されました。このスケジューラーはスケジュールするタスクの数に関わらず、一定時間で動作することから、O(1) スケジューラーと名付けられました。このスケジューラーの詳細については、「Linux スケジューラーの内側」(developerWorks、2006年6月) を読んでください。
  • O(1) スケジューラーに続き CFS が発表され、Linux カーネルに採用されました。CFS は、すべてのプロセスに使用可能なプロセッサーを均等に割り当てるという概念に基づきます。その公平性は、この記事に記載した例で、最小優先度のプロセスも含めたすべてのプロセスにプロセッサーへのアクセスが割り当てられたことから明らかです。CFS の詳細については、「Linux カーネル 2.6 Completely Fair Scheduler の内側」(developerWorks、2009年12月) を読んでください。
  • LTTng (Linux Trace Toolkit next generation) は、カーネルおよびユーザー空間のアクティビティーを追跡するユーザー空間の可視化機能を提供します。このツールはシステムの振る舞いを理解するのに役立ち、ソフトウェアの問題だけでなくパフォーマンスの問題をデバッグできるようにします。Distributed Multi-Core Tracing Research Project もまた、役に立つサイトです。このプロジェクトでは、マルチコア・システムを最小限のオーバーヘッドでトレースするための技術とアルゴリズムを開発しています。
  • Linux カーネルに実装されたアルゴリズムを含め、スケジューリングについて詳しく学ぶには、ウィキペディアの「スケジューリング」ページを調べてください。このページには、FIFO およびラウンドロビン方式のスケジューリングの説明に加え、主要なオペレーティング・システムのそれぞれで使用しているスケジューラーについても簡単に要約しています。
  • developerWorks Linux ゾーンで、Linux 開発者および管理者向けのハウツー記事とチュートリアル、そしてダウンロード、ディスカッション、フォーラムなど、豊富に揃った資料を探してください。
  • さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
  • 無料の developerWorks Live! briefing に参加して、IBM の製品およびツール、そして IT 業界の傾向を素早く学んでください。
  • developerWorks の on-demand demos で、初心者向けの製品のインストールとセットアップから、熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
  • Twitter で developerWorks をフォローするか、developerWorks で Linux に関するツイートのフィードに登録してください。

製品や技術を入手するために

  • ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。

議論するために

  • My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=650372
ArticleTitle=Linux スケジューラーのシミュレーション
publish-date=02232011