Operating Systems
📂 Introduction
· 2 of 5
50 min read
Computer System Organization & Types of Operating Systems
A complete Galvin-style deep dive into how a computer is organized — bus architecture, storage hierarchy from CPU registers down to cloud tape, the I/O subsystem with device controllers, DMA, and interrupts — plus every major OS type: Batch, Multiprogramming, Multitasking, Time-Sharing, Real-Time (hard/soft/firm), Distributed, Network, Clustered, Embedded, and Mobile. Includes live animated SVG diagrams and hands-on Linux examples.
Section 01
Computer System Organization — The Big Picture
📖 Real World Analogy
The Modern Kitchen Brigade
Picture a busy restaurant kitchen. The head chef (CPU) executes the
recipe. She keeps ingredients she needs right now on the counter
(registers), her most-used spices in a nearby rack
(cache), the day's stock in a walk-in fridge (RAM),
frozen supplies in the freezer (SSD/HDD), and long-term reserves in
a distant warehouse (tape / cloud archive).
Meanwhile, the waiters (I/O controllers) shuttle orders in and plates
out, and the system bus is the shared corridor everyone walks through.
A computer is exactly that kitchen: the closer to the CPU, the smaller, faster,
and more expensive the storage — and everything meets on shared buses.
Animated System Diagram — Bus, CPU, Memory, and Controllers
A Modern Computer at Work
🔌
Key Insight — Everything Shares One Bus
CPU and device controllers can all execute concurrently, but they compete
for the memory bus. A memory controller arbitrates accesses so no one corrupts
another's data. This is why bus bandwidth — not raw CPU speed — is often the real
bottleneck in modern systems.
Section 02
Storage Structure — The Memory Hierarchy
No single storage technology is fast, huge, cheap, and non-volatile all at once. So we
build a hierarchy: multiple layers, each trading speed for capacity.
The OS is what keeps data flowing between them.
Animated Storage Pyramid — Speed vs Size vs Cost
The Memory Hierarchy — Data Flows Up and Down
Layer
Access Time
Size
Volatile?
Managed By
CPU Registers
~0.3 ns
< 1 KB
Yes
Compiler
L1 Cache
~1 ns
32-64 KB
Yes
Hardware
L2 / L3 Cache
3-10 ns
256 KB - 64 MB
Yes
Hardware
Main Memory (RAM)
~100 ns
8 - 128 GB
Yes
Operating System
SSD (NVMe / SATA)
50 - 100 μs
256 GB - 4 TB
No
Operating System
HDD (Magnetic)
3 - 10 ms
1 - 20 TB
No
Operating System
Optical / Tape
Seconds
Unlimited
No
Operator / Software
🔑
Caching — The Universal Optimisation
Caching means copying data from a slower layer to a faster one because it will likely
be reused soon (temporal locality) or its neighbours will be needed
(spatial locality). The same idea repeats at every boundary — CPU
cache, OS disk cache, DNS cache, browser cache, CDN. Same principle, different scale.
Practical — Inspect Your Own Memory Hierarchy
# Linux — cache sizes at every level
$ lscpu | grep -i cache
L1d cache: 128 KiB (4 instances)
L1i cache: 128 KiB (4 instances)
L2 cache: 1 MiB (4 instances)
L3 cache: 8 MiB (1 instance)
# RAM overview
$ free -h
total used free buff/cache available
Mem: 15Gi 6.1Gi 2.4Gi 7.1Gi 8.5Gi
Swap: 4.0Gi 128Mi 3.9Gi
# Storage devices — block layer
$ lsblk
NAME SIZE TYPE MOUNTPOINT
nvme0n1 512G disk
├─p1 512M part /boot/efi
└─p2 511.5G part /
OBSERVATION
The "buff/cache" column in `free` is the OS's disk cache — RAM used to speed
up file I/O. It looks "used" but is instantly reclaimable when a process needs memory.
Section 03
I/O Structure — How the CPU Talks to Devices
Every I/O device is managed by a small dedicated processor called a
device controller. It exposes a set of registers and a local buffer.
The CPU never touches the raw device — it talks only to the controller.
Animated Device Controller — CPU, Controller, and Device
The Middleman — Device Controller in Action
3.1 Three Techniques of I/O
🕑
Polling (Programmed I/O)
CPU busy-waits
CPU repeatedly asks "are you ready?" in a tight loop. Simple but wastes almost every
cycle waiting.
+ Trivial to implement- CPU 100% burned on a slow device
🔔
Interrupt-Driven I/O
Device signals CPU
CPU starts the transfer and moves on to other work. Controller raises an interrupt
when done.
+ CPU free during transfer- One interrupt per byte is costly for big transfers
🚀
Direct Memory Access (DMA)
DMA controller
A dedicated DMA engine moves whole blocks between device and RAM without CPU. One
interrupt per block.
+ Ideal for disks, network, GPU- Adds hardware complexity, bus contention
Not all operating systems solve the same problem. Workload, response-time requirement,
and hardware shape the design. Galvin lists several major families — we'll cover the
full set.
Animated Overview — All OS Types Rotating Around Purpose
The OS Family Tree
Section 05
Deep Dive — Batch Operating System
📖 Story
The Post Office at Night
Letters pile up in a bin all day. At night, one worker picks them one by one, sorts each,
seals it, and moves to the next — never pausing for a customer. That is a batch OS: a
queue of jobs, an operator who submits them, and a system that runs them back-to-back
with zero human contact until the batch is done.
Animated Batch Timeline — Serial Execution
One Job at a Time · CPU Idle During I/O
✅ Advantages
Simple, predictable, low overhead
Perfect for repetitive, non-interactive workloads
High throughput for compute-heavy jobs
❌ Drawbacks
CPU sits idle during I/O
No interaction — cannot fix a wrong input midway
Long turnaround time
💼
Batch is Not Dead
Modern payroll runs, nightly ETL jobs, ML training queues, and CI/CD pipelines
are all batch workloads. Tools like cron, Kubernetes
Jobs, and Slurm are direct descendants of batch operating systems.
Section 06
Deep Dive — Multiprogramming OS
Batch systems waste the CPU during I/O. Multiprogramming fixes this by
keeping multiple jobs in memory at once. When one blocks on I/O, the
OS switches to another. The CPU is always doing useful work.
Animated Comparison — Batch vs Multiprogramming
Overlapping CPU with Someone Else's I/O
🔑
What Multiprogramming Needs
Memory management to hold multiple jobs safely.
CPU scheduling to pick who runs next.
I/O management to start transfers and dispatch on completion.
This is exactly why memory + scheduling + I/O are the core OS subsystems.
Section 07
Deep Dive — Multitasking & Time-Sharing OS
Multiprogramming solved CPU utilisation, but it did not care about response time.
Users waiting at a terminal want their prompt back in milliseconds. Time-sharing
(a form of preemptive multitasking) solves this by giving every process a small
time slice.
Animated Time Slice Rotation — Round-Robin Scheduling
The Time Quantum Cycle
Property
Multiprogramming
Multitasking / Time-Sharing
Switch trigger
I/O wait
Timer interrupt (preemptive)
Goal
Maximise CPU use
Minimise user response time
User interaction
Little / none
Interactive terminals / GUI
Typical era
1960s
1970s → today
Examples
Early IBM OS/360
UNIX, Windows, macOS, Linux
# Linux — see scheduling policy and quantum
$ chrt -p 1
pid 1's current scheduling policy: SCHED_OTHER
pid 1's current scheduling priority: 0
# Watch context switches per second
$ vmstat 1
procs -----------memory---------- --system-- ------cpu-----
r b swpd free buff cache in cs us sy id wa
2 0 131k 2.4G 412M 7.1G 5012 14827 8 3 88 1
▲ ▲
interrupts context switches
Section 08
Deep Dive — Real-Time Operating Systems (RTOS)
📖 Story
The Airbag That Cannot Be "Almost On Time"
Your car detects a collision. The airbag controller has exactly 15 milliseconds
to fire before your head reaches the steering wheel. A general OS that "usually"
responds in 20 ms is worse than useless here — it will kill people. An RTOS
guarantees the airbag task runs within its deadline, every single time, no exceptions.
Animated Deadline Race — RTOS vs General-Purpose OS
Missing a deadline degrades quality but is not fatal. Multimedia, VoIP, streaming,
gaming. Linux with PREEMPT_RT, Windows CE.
video, audio, games
🟢
Firm Real-Time
Occasional miss is tolerable but the result becomes useless after the deadline.
Stock trading, telemetry, live sensors.
HFT, telemetry
⚠️
Why a Normal OS Cannot Do Hard RT
Linux and Windows optimise for average throughput. Their kernels can hold interrupts
off for milliseconds during garbage collection, page faults, or driver locks. An
RTOS has a bounded worst-case latency — usually a few microseconds —
enforced by design.
Characteristic
General-Purpose OS
Real-Time OS
Primary goal
Fairness & throughput
Predictable deadlines
Scheduler
Priority + fairness (CFS)
Priority-based, deterministic
Kernel size
Millions of lines
Tens of thousands (small & auditable)
Interrupt latency
~100 μs (variable)
< 10 μs (bounded)
Memory model
Virtual memory, paging
Often no paging (avoids jitter)
Section 09
Deep Dive — Distributed & Clustered Operating Systems
A distributed OS makes a collection of independent, networked computers
appear to the user as a single coherent system. A clustered OS is a
close cousin — a group of tightly-coupled machines cooperating for high availability or
high performance.
Animated Distributed System — Many Nodes, One Illusion
Clustered vs Distributed vs Network OS — Not the Same Thing
Type
Coupling
Illusion Provided
Example
Network OS
Loose
User knows about each remote machine (ssh, ftp)
Any Linux/Windows with networking
Distributed OS
Tighter
User sees a single system image
Amoeba, Plan 9, LOCUS
Clustered OS
Very tight (LAN)
High availability or HPC
Windows Server Failover, Beowulf, Oracle RAC
Section 10
Deep Dive — Embedded & Mobile Operating Systems
🔌
Embedded OS
Dedicated · Tiny
Runs on a device built for one purpose — a router, smart bulb, thermostat, ATM.
Small footprint (KB to MB), often no user interface. Contiki, TinyOS, FreeRTOS.
📱
Mobile OS
Touch · Battery-aware
Full OS optimised for touch UI, sensors, radios, and battery life. Sandboxed
applications, app store distribution, cellular integration. iOS, Android, HarmonyOS.
🌐
Cloud OS
Virtualised · Elastic
A hypervisor + management layer that presents data-centre hardware as elastic
resources (VMs, containers). AWS, Azure, GCP, OpenStack.
Section 11
Side-By-Side — All OS Types Compared
Type
Primary Goal
User Interaction
Response Time
Example
Batch
Throughput
None
Hours
Nightly payroll, IBM OS/360
Multiprogramming
CPU utilisation
Minimal
Minutes
Mainframe batch + I/O overlap
Multitasking
Concurrent programs
High
Seconds
Windows, macOS, Linux desktop
Time-Sharing
Fair CPU per user
High (multi-user)
Milliseconds
UNIX servers, SSH boxes
Real-Time (Hard)
Deadline guarantee
Machine-only
Microseconds (bounded)
Airbags, pacemakers, VxWorks
Distributed
Resource sharing across nodes
Transparent
Network-dependent
Plan 9, Amoeba (ideas in K8s)
Clustered
High availability / HPC
Transparent
Low failover latency
Beowulf, Oracle RAC
Embedded / Mobile
Specific device function
Touch / voice / none
Real-time-ish
iOS, Android, FreeRTOS
Section 12
Practical — Which OS Type Fits Which Problem?
📂
Batch
Bulk data processing with no user in the loop — payroll, invoices, ETL, ML training.
throughput matters, latency doesn't
🖥️
Multitasking
Personal computing — browsing, coding, editing, media playback all at once.
laptops, workstations
💻
Time-Sharing
Shared servers where many developers log in simultaneously — bastion hosts, dev boxes, university labs.
SSH multi-user boxes
🚗
Real-Time
Missing a deadline hurts people or equipment — avionics, medical devices, industrial robots, automotive ECUs.
safety-critical
🏘️
Distributed / Clustered
Workloads too big for one machine — search engines, social networks, big-data analytics, cloud services.
The storage hierarchy exists because no single technology is fast, huge, cheap, and non-volatile. The OS constantly moves data up on demand and down when evicted.
2
Caching is universal. The same locality principle appears at CPU cache, RAM disk cache, browser cache, and CDN. Recognising it saves you re-learning it in every subject.
3
The CPU never touches devices directly. It talks to device controllers via bus registers and memory-mapped I/O. This makes drivers, DMA, and interrupts finally click.
4
DMA is the single biggest reason modern computers feel fast. It lets megabytes flow between disk/network and RAM while the CPU does real work.
5
Multiprogramming, multitasking, and time-sharing are a progression — each solves a limitation of the previous. Learn them in that order and the design choices become obvious.
6
Real-time is about predictability, not raw speed. A "slow" RTOS that always meets a 10 ms deadline beats a "fast" Linux that occasionally takes 50 ms.
7
A pure distributed OS is rare today, but its ideas — transparency, replication, consensus, fault tolerance — are the foundation of everything cloud-native.
8
Modern computing is a mix: your phone is mobile + soft-RTOS + embedded; a cloud server is multitasking + time-sharing + clustered. OS types aren't mutually exclusive.