Evaluating operating system design

Overview

Recall questions on the trade-offs in time-slice length, memory partitioning and interrupt priorities, why virtual memory risks performance, why more processes eventually reduce throughput, why real-time and embedded systems are simpler, the cost of the user and kernel mode division, and why no scheduling policy is best in general.

What you need to know

Answer each one before you reveal it.

Questions from this subtopic

Each one with the model answer underneath.

1. 1

   Why is operating system design described as a set of trade-offs?

   Model answer

   Responsiveness, throughput, fairness and simplicity pull against each other, so improving one usually costs another.

2. 2

   Give the trade-off in choosing a time-slice length.

   Model answer

   A short slice gives smoother responsiveness but more context-switching overhead; a long slice does more useful work but makes the system feel sluggish.

3. 3

   Give the trade-off in memory partitioning.

   Model answer

   Fixed partitions are simple but waste space within them; dynamic partitions fit exactly but leave unusable gaps between them.

4. 4

   Give the trade-off in interrupt priorities.

   Model answer

   Strong prioritisation protects urgent work but risks starving low-priority tasks, and ageing costs bookkeeping to prevent it.

5. 5

   Why does virtual memory improve capability but risk performance?

   Model answer

   It lets programs exceed physical memory, but every page fault costs a disc access thousands of times slower than memory.

6. 6

   Why does adding processes eventually reduce total throughput?

   Model answer

   Beyond the point where working sets no longer fit in memory, paging and switching consume the capacity the extra processes were meant to use.

Other ways to work this

The same content, four other ways.

What is inside Levo

Six ways to work the same material.