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

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
Disk Controller SSD / HDD USB Controller Keyboard · Mouse Network Card Ethernet · WiFi SHARED SYSTEM BUS CPU Registers · Cache L1 · L2 · L3 Main Memory DRAM · 8-128 GB ~100 ns access GPU / Graphics Video output DisplayPort · HDMI Colored packets show data flowing over the shared bus — only one talker at a time
🔌
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
Registers ~0.3 ns · < 1 KB · on-chip L1 Cache ~1 ns · 32-64 KB · per core L2 Cache ~3 ns · 256 KB-1 MB L3 Cache ~10 ns · 4-64 MB · shared Main Memory (RAM) ~100 ns · 8-128 GB · DRAM Solid-State Drive (SSD) ~50 μs · 256 GB-4 TB · flash Hard Disk Drive (HDD) ~5 ms · 1-20 TB · magnetic Tape / Cloud Archive seconds · unlimited · offline ▲ Faster ▲ Smaller ▲ Costlier ▼ Slower ▼ Bigger ▼ Cheaper ↑ CPU reads data (bubble up) ↓ Eviction (spill down)
Layer Access Time Size Volatile? Managed By
CPU Registers~0.3 ns< 1 KBYesCompiler
L1 Cache~1 ns32-64 KBYesHardware
L2 / L3 Cache3-10 ns256 KB - 64 MBYesHardware
Main Memory (RAM)~100 ns8 - 128 GBYesOperating System
SSD (NVMe / SATA)50 - 100 μs256 GB - 4 TBNoOperating System
HDD (Magnetic)3 - 10 ms1 - 20 TBNoOperating System
Optical / TapeSecondsUnlimitedNoOperator / 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
CPU Issues command Handles interrupt Controller Buffer · Registers Handles the device Device Disk · Keyboard Printer · NIC BUS CABLE Interrupt: "I'm done!" CPU dispatches command → controller does the work → interrupt on completion Blue = command · Purple = data returning · Red = interrupt

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

Animated Comparison — Polling vs Interrupt vs DMA

CPU Load — Three I/O Techniques Side by Side
POLLING CPU busy 100% asking "ready? ready? ready?" INTERRUPT CPU free most of the time — interrupts on each byte DMA ◄─── whole block moves here without CPU ───► 1 IRQ Solid red = CPU 100% busy · Amber bars = interrupt handling · One green bar = "done" IRQ DMA wins by ~4000× for a 4 KB transfer (1 IRQ vs 4096 IRQs)

3.2 Interrupt Life Cycle

What Happens on Every Interrupt
User process runs ⚡ IRQ Save state → switch to kernel mode Run Interrupt Service Routine (ISR) Restore state → back to user User process resumes Timeline → 1. Running normally 2. Device raises IRQ 3. Kernel handles it (ISR) 4. Resume as if nothing happened
# Linux — watch interrupts happening live per CPU
$ watch -n1 'cat /proc/interrupts | head'
           CPU0    CPU1    CPU2    CPU3
  0:        21       0       0       0   IO-APIC   2-edge      timer
  8:         1       0       0       0   IO-APIC   8-edge      rtc0
 24:    148237   93411   75102   68240   PCI-MSI   nvme0q0    # disk
 25:     22884   31017   27339   29128   PCI-MSI   iwlwifi    # wifi

Section 04

Types of Operating Systems — Overview

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
Operating System Batch 1960s Multi- programming Multi- tasking Time- Sharing Real- Time Distri- buted Clustered HA / HPC Embedded & Mobile Eight major families — each a response to a specific workload

Section 05

Deep Dive — Batch Operating System

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
t = 0 time → Job 1 CPU I/O idle Job 2 CPU I/O idle Job 3 ✗ CPU IDLE during every I/O wait BATCH OS Timeline Jobs run strictly one after another — no overlap
✅ 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
MULTIPROGRAMMING Timeline Job 1 Job 2 Job 3 CPU CPU utilised nearly 100% ■ solid = CPU ▨ dashed = I/O wait Trick: overlap CPU bursts with someone else's I/O Playhead sweeps across time — someone is always running on the CPU
🔑
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
CPU 1 core P1 Editor P2 Browser P3 Music P4 Chat P1 · 10ms P2 · 10ms P3 · 10ms P4 · 10ms Timer interrupt fires every quantum → scheduler rotates to the next process
PropertyMultiprogrammingMultitasking / Time-Sharing
Switch triggerI/O waitTimer interrupt (preemptive)
GoalMaximise CPU useMinimise user response time
User interactionLittle / noneInteractive terminals / GUI
Typical era1960s1970s → today
ExamplesEarly IBM OS/360UNIX, 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)

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

Which One Meets the Deadline Every Time?
DEADLINE (15 ms) General OS sometimes late ✗ RTOS always on time ✓ RTOS trades peak speed for absolute predictability
🔴
Hard Real-Time
Missing a deadline = catastrophic failure. Airbags, pacemakers, avionics, industrial robots. Systems: VxWorks, QNX, INTEGRITY, RTEMS.
safety-critical
🟠
Soft Real-Time
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.

CharacteristicGeneral-Purpose OSReal-Time OS
Primary goalFairness & throughputPredictable deadlines
SchedulerPriority + fairness (CFS)Priority-based, deterministic
Kernel sizeMillions of linesTens of thousands (small & auditable)
Interrupt latency~100 μs (variable)< 10 μs (bounded)
Memory modelVirtual memory, pagingOften 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

Nodes Cooperating Over the Network
Node A CPU · RAM Disk Node B CPU · RAM Disk Node C CPU · RAM Disk Node D CPU · RAM Disk NETWORK (Ethernet / InfiniBand) Single System Image Users see one giant computer The OS hides the network — reading a "local" file may actually fetch over TCP
✅ Benefits
Resource sharing — CPU, files, printers
Speedup — split jobs across nodes
Reliability — one node dies, others take over
Scalability — add more nodes for more power
❌ Challenges
Network is unreliable and slow vs local RAM
Clock synchronisation (NTP, Lamport, vector clocks)
Distributed deadlocks & consensus (Paxos, Raft)
Security surface is huge

Clustered vs Distributed vs Network OS — Not the Same Thing

TypeCouplingIllusion ProvidedExample
Network OSLooseUser knows about each remote machine (ssh, ftp)Any Linux/Windows with networking
Distributed OSTighterUser sees a single system imageAmoeba, Plan 9, LOCUS
Clustered OSVery tight (LAN)High availability or HPCWindows 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.
horizontal scale, HA
📱
Embedded / Mobile
Battery- and memory-constrained dedicated devices — smart bulbs, watches, thermostats, phones.
IoT, wearables, appliances

Section 13

Golden Rules — What to Remember

📚 System Organization & OS Types — Foundations
1
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.