Start here

CPU burst = continuous stretch using the CPU. I/O burst = stretch waiting on devices/network. Schedulers use these profiles to balance response time vs throughput.

Burst characterization

Interactive workloads often show short CPU bursts between long waits; batch/HPC jobs may show long CPU bursts. Misclassifying a workload leads to wrong quanta, wrong cgroup weights, or wrong autoscaling rules.

By the end of this page you should be able to

Give one reason CPU utilization can be low while latency is high.
Relate convoy effect to CPU burst ordering under simple FCFS.
Explain why profiling must be repeated after code changes.

Operating systems · Processes

CPU burst vs I/O burst

Modeling workload phases for scheduling

TL;DR

CPU burst = continuous CPU execution without blocking; I/O burst = phase waiting on devices. Classical scheduling algorithms assume a distribution of CPU bursts; interactive workloads have short CPU bursts and frequent I/O waits, shaping scheduler design (RR, MLQ).

Summary

Burst models are not academic trivia, they explain why naive FCFS convoys batch jobs behind one monster CPU loop and why MLFQ tries to infer “interactive” behavior.

Deeper narrative

Workload characterization drives scheduler choice: interactive tasks need low response time (short CPU bursts between I/O waits); batch jobs maximize throughput. Profilers classify bursts to tune quantum, priority bands, and cgroup weights.

Mechanism (step by step)

Treat each step as a sentence in the story you tell on a whiteboard.

Observe inter-arrival

Trace syscalls or block I/O histograms to estimate burst distribution.

Classify

CPU-bound vs I/O-bound vs mixed; tail latency sensitive vs throughput sensitive.

Map to policy

RR for fairness among interactives; CFS weights for service tiers; BFQ for spinning disks.

Validate

Measure p99 latency and CPU utilization jointly, avoid optimizing one metric blindly.

Key insights

Each card is a compression of the lesson, use them as spaced-repetition prompts.

Predictability vs reality

SJF needs future burst lengths, usually unknown; approximations use past behavior or hints.

Interactive feel

Short time quanta help RR for bursty terminals; too short raises context switch overhead.

Mixed workloads

Multilevel queues segregate batch vs interactive classes to prevent mutual interference.

Energy-aware scheduling

Mobile OSes stretch I/O waits to batch radio wakeups, OS policy aware of burst patterns beyond CPU-only.

Did you know?

Trivia with teeth: the kind of fact that changes how you reason about a design.

Batch jobs can be CPU-bound for hours; schedulers may still preempt them for fairness unless cgroups cap shares.

SSD latency collapsed many I/O burst durations vs HDD, changing empirical scheduler tuning.

Profiling tools classify threads as on-CPU vs off-CPU to visualize bursts.

Common pitfalls

Where smart people still trip, read slowly.

Assuming I/O-bound means low CPU

Compression/serialization can flip phases under load, re-profile after changes.

Micro-benchmark bias

Hot loops look CPU-bound; real systems wait on locks and RPCs.

Comparison

CPU-bound vs I/O-bound (operational view)

Signal	CPU-bound-ish	I/O-bound-ish
`top` CPU%	High for thread	Low for thread
`iostat` await	Low if disk idle	High when waiting on storage
Scheduler impact	Quantum/fairness matters	Wake latency + block layer matters

Another lens

Workload → scheduler hint

Profile	Hint
Interactive short bursts	Small quantum / latency-oriented class
Batch HPC	Longer slices, affinity, avoid migration
Mixed cloud	cgroups + autoscaling, not one global knob

Glossary

CPU burst

Continuous CPU execution segment before blocking or preemption.

I/O burst

Interval waiting on devices or network without consuming CPU.

Convoy effect

Interview follow-ups

Why does SJF favor I/O-bound workloads if bursts known?
How does blocking affect CPU utilization percentage?
What metric shows convoy under FCFS?

Callouts

Interview tie-in

Relate off-CPU time in `perf` to “I/O burst” when narrating tail latency fixes.

Walkthrough & deep dive

Left: practical “how would I use this?” threads. Right: slower, code-leaning explanations, open one panel at a time so the page does not feel like a wall of sameness.

Walkthrough

Classify

Pick three daemons on your machine and classify each as CPU-, I/O-, or network-bound with evidence.

Deep dive

Convoy effect

One long CPU burst delays everyone behind it in FCFS, motivates preemptive policies.

Off-CPU sampling (concept)

Terminal

# perf record -g -a -- sleep 5
# perf report --sort=comm,dso

Self-check

Misses here are cheap; misses in an interview are not. Treat wrong answers as a patch list for tomorrow.

1A long CPU burst under FCFS tends to…

2Interactive programs often exhibit…

3SJF optimality statements assume…