Home › GATE CSE › computerscience › Operating Systems › Increasing the RR time slice from 1 ms to 100 ms…
Increasing the RR time slice from 1 ms to 100 ms generally has what effect on the system?
AReduces context-switch overhead but worsens response time
BIncreases context-switch overhead and improves response time
CHas no effect on either
DEliminates the need for the scheduler entirely
Answer & Solution
Correct answer: A. Reduces context-switch overhead but worsens response time
1. OSTEP §7.6 discusses the time-slice trade-off explicitly.
2. CONTEXT SWITCH OVERHEAD: each switch costs CPU cycles (save/restore registers, flush TLB caches, etc.). Larger time slices → FEWER switches per unit time → LESS overhead.
3. RESPONSE TIME: a job has to wait for OTHER jobs to use their time slice before its turn. Longer slices → longer wait → WORSE response.
4. Trade-off: small slices (e.g. 1 ms) → great response, high overhead. Large slices (e.g. 100 ms or more) → low overhead, sluggish response.
5. Practical Linux default: ~10 ms (e.g. CONFIG_HZ_100=10ms).
6. Options B, C, D either invert or ignore the trade-off.
_Source: OSTEP Ch 7, §7.6 (Round Robin — time-slice trade-off), p. 8._
Related questions
On a MULTI-CORE system, a SPIN LOCK is generallyDisabling INTERRUPTS as a way to implement mutual exclusion on a single-CPU system isA LIVELOCK differs from a DEADLOCK in thatSuppose thread A acquires lock L1, then thread B acquires lock L2. Now A tries to acquire Without atomic hardware support, building a correct mutual-exclusion lock for $N \geq 2$ tA CRITICAL SECTION isLinux's `pthread_mutex_lock()` is typically implemented as a HYBRID:What is the PRIMARY problem with using a SPIN LOCK on a SINGLE-CPU uniprocessor system (wi