7

ラウンドロビンスケジューラのタイムスライスが非常に大きい(たとえば大きすぎる)場合、オペレーティングシステムでどのようなパフォーマンス効果を期待する必要がありますか?

私の唯一の考えは、多くの時間を必要とするプロセスにはメリットがありますが、ほとんどのプロセスはわずかな時間を使用するため、すべての小さなプロセスの完了に遅延が発生するということですか?

例:タイムスライス50、プロセスP1 = 400、P2 = 10、P3 = 150、P4 = 20、P5 = 10、P6 = 10

これは、タイムスライスが小さすぎるか大きすぎる限り、皆さんが共有できるものがあるかどうか疑問に思っている私の最善の推測です。

4

2 に答える 2

7

ラウンドロビンの問題は、タスクが等しくないことです。

CPUバウンドタスクの場合。非常に重要なタスクと何千もの重要でないタスクがある場合、それらの重要でないタスクはすべて、重要なタスクのパフォーマンスを低下させます。この場合、タイムスライスの大きさは関係ありません。

IOバウンドタスクの場合、ラウンドロビンは遅延を引き起こします。重要なタスクのブロックが解除された場合(たとえば、「sleep()」を呼び出した後にウェイクアップしたり、待機していたファイルIOを受信したりするなど)、重要なタスクの前に、何千もの重要でないタスクがタイムスライスを通過するのを待たなければならない場合があります。何でもするチャンスがあります。タイムスライスの長さを短くすると、重要なタスクが何か有用なことを開始するまでにかかる時間が短縮されますが、重要なタスクが何か有用なことを実行できるようになるまでの時間も短縮されます。

注:ブロックを解除するタスクをリストの先頭に移動させることで、これを「修正」したくなる場合があります。この場合、重要でないタスクが眠り、目覚め続けるという理由だけで、重要なタスクが永遠に飢えている可能性があります。

基本的に、ラウンドロビンは「役に立たない」ものの山であり、さまざまなタスクの重要性/優先度を少なくともある程度尊重する完全に異なるスケジューリングアルゴリズムに置き換えるまで、何をするかは重要ではありません。

過度に単純化された例の場合。3つの異なるタスク優先度を設定できます。この場合、OSは可能な限り最高の優先度のタスクのみを実行し(優先度の高いタスクが優先度の低いタスクをすぐにプリエンプトすることを確認するなど)、同じ優先度のタスクにラウンドロビンが使用されます。この場合、優先度ごとにタイムスライスの長さを変えることができます(たとえば、優先度の高いタスクは1ミリ秒、優先度の低いタスクは10ミリ秒、優先度の低いタスクは125ミリ秒)。

「あまり単純化されていない」例の場合。いくつかの完全に異なるスケジューリングポリシー(たとえば、リアルタイムタスク用、通常タスク用、バックグラウンド/アイドルタスク用)を設定できます。これらはすべて異なるアプローチ(たとえば、最も早い期限、可変タイムスライスなど)を使用します。ここで、各スケジューリングポリシーには256のタスク優先順位があります。

于 2012-11-29T05:58:45.463 に答える
0

タイムスライスの観点から、パフォーマンスを低下させる2つの極端なシナリオがあります。タイムスライスが次の場合:

  1. 大きすぎる:タイムスライスが小さければ、小さなプロセスがはるかに早く終了する可能性がある場合に、非常に長い時間待機します。また、これは、より短いが頻繁なCPU時間を必要とする対話型プロセスには適していません。
  2. 小さすぎる:頻繁なコンテキストスイッチが発生し、かなりのオーバーヘッドが発生します。

歴史的に、OS開発者は、これら2つの極端なバランスをとるために懸命に努力してきました。また、パフォーマンスを向上させるためにラウンドロビンを採用するさまざまな優先度ベースのアルゴリズムがあります。

于 2016-02-18T04:26:55.517 に答える