Time fragments in a Robin timeline

If you have a very large (say, too large) time slice for a circular scheduler, what performance effect should I expect in the operating system?

My only thought is that processes requiring a large amount of time will benefit, but most processes use a small amount of time, so will this delay the completion of all smaller processes?

Example: time intervals 50 and processes P1 = 400, P2 = 10, P3 = 150, P4 = 20, P5 = 10, P6 = 10

This is my best guess. I am wondering if there is anything that you guys could share, as the time slice is too small or too large.

+7
source share
2 answers

The problem with round robin is that the tasks are not equal.

For tasks related to CPU; if you have an extremely important task and thousands of unimportant tasks, then all these non-essential tasks are detrimental to the performance of the important task. For this case, it does not matter how large the time slices are.

For tasks related to IO, cyclic robin causes a bad delay. If an important task is unlocked (for example, it wakes up after calling "sleep ()", receives the IO file that he expected, etc.), then you may have to wait until thousands of unimportant tasks work through their time fragments before the important task gets a chance to do something. Reducing the length of the time slice will reduce the time required for an important task to start doing something useful, but also reduce the time that an important task will do for something useful.

Note. You may be tempted to β€œfix” this by setting tasks that unlock to go to the top of the list. In this case, fasting forever can be an important task only because unimportant tasks continue to sleep and wake up.

In fact, round-robin is a bunch of missing β€œuseless” ones, and it doesn't matter what you do until you replace it with a completely different scheduling algorithm, which at least has some respect for the importance / priority of various tasks.

For a simplified example; you can have 3 different task priorities, when the OS always runs tasks with the highest priority (including to ensure that tasks with a higher priority pursue tasks with a lower priority immediately), and the circular mode is used for tasks with the same priority. In this case, you could have different slice lengths for different priorities (for example, tasks with high priority receive only 1 ms, tasks with priority priority - 10 ms, tasks with low priority - 125 ms).

For example, "less simplified"; you can have several completely different scheduling policies (for example, one for real-time tasks, one for normal tasks, one for background / idle tasks) that use different approaches (for example, the earliest deadline, variable time slice, etc. ); where 256 task priorities for each planning policy.

+6
source

In terms of time reduction, there are 2 extreme scenarios that reduce productivity. If time slice:

  • Too big: makes small processes wait a very long time, when they could finish much earlier if the time cut was less. In addition, it is not beneficial for interactive processes that require less, but frequent processor time.
  • Too little: causes frequent context switches, which is a significant overhead.

Historically, OS developers have worked hard to find a balance between these two extremes, and there are various priority algorithms based on which get absorbed with Round-Robin for better performance.

0
source

All Articles