Operating Systems Expert

Both modes have identical hardware privileges, but kernel mode simply runs its threads at a higher scheduling priority.

User mode has unrestricted hardware access, while kernel mode is restricted to running only trusted signed applications.

Kernel mode runs user applications directly, while user mode handles interrupts and manages the physical memory pages.

Kernel mode has unrestricted hardware access, while user mode is restricted and must use system calls to reach hardware.

It directly executes application logic within the hardware, bypassing any need for a resource management layer.

It compiles application source code and provides a graphical interface used for editing that same code directly.

It stores user data permanently and provides encryption, but it does not manage CPU scheduling or memory allocation.

It manages hardware resources and provides an abstraction layer between applications and the physical hardware.

Instructions affecting hardware or control state directly; in user mode they would let apps bypass OS protection, so they run only in kernel mode.

Instructions that access encrypted memory regions; because keys live in the kernel, user mode cannot decode them, so they run privileged only.

Instructions that run faster than normal ones; user mode disables them merely for speed reasons, so they are reserved for the kernel to keep timing fair.

Instructions written only in assembly language; user programs use high-level code, so these low-level operations are handled exclusively by the kernel.

A distributed OS runs on a single isolated machine, while an embedded OS coordinates many networked computers as one system.

A time-sharing OS meets hard deadlines, while an embedded OS lets many users share one large mainframe interactively.

A real-time OS meets strict deadlines, while a time-sharing OS switches the CPU among users to give interactive response.

A batch OS gives interactive response, while a real-time OS processes jobs in bulk with no direct user interaction at all.

Splitting a single program across many CPUs so each processor executes part of the work to finish the job faster.

Running one job at a time to completion so the CPU never idles while waiting for slow input or output devices.

Giving each user a short time slice in turn so an interactive terminal always feels responsive to the person using it.

Keeping several jobs in memory so the CPU runs another job whenever one waits for I/O, so the CPU stays busy.

Type 1 uses containers for its isolation, while Type 2 relies on full hardware virtualization for guests.

Type 1 runs directly on the hardware, while Type 2 runs as an application on top of a host OS.

Type 1 runs as an application on a host OS, while Type 2 runs directly on the bare-metal hardware.

Type 1 can only run Linux guests, while Type 2 is the only kind that supports Windows guest systems.

BIOS/UEFI loads user applications, while the bootloader runs power-on self-tests and initializes CPU registers.

The bootloader initializes the hardware first, then the BIOS/UEFI loads the OS kernel directly into memory.

The OS kernel loads first and then invokes the BIOS/UEFI to locate and start the bootloader program itself.

BIOS/UEFI initializes hardware and locates the bootloader, which then loads the OS kernel into memory.

In SMP processors never share any memory; in AMP processors share all memory and run identical scheduling code as equal peers.

In SMP all CPUs are peers sharing memory and the OS; in AMP a master CPU controls subordinates assigned specific tasks.

In SMP each CPU runs its own separate OS copy; in AMP all CPUs share one OS image and treat every processor identically.

In SMP one master CPU assigns all work; in AMP the CPUs are peers that share memory and schedule the OS equally.

Protection controls internal access of processes and users to resources; security defends the whole system from external threats.

Protection and security are identical terms, both describing how the OS authenticates remote users before granting resource access.

Protection encrypts data against outside attackers; security assigns file permissions to internal users reaching shared system resources.

Protection guards against external intruders and malware; security governs how internal processes are allowed to reach system resources.

Both kernels run all their services in user space, so they differ only in scheduling policy rather than in stability or speed.

Monolithic kernels run most services in kernel space for speed, while microkernels isolate services in user space for stability.

Monolithic kernels offer better modularity and stability, while microkernels always outperform them due to far fewer context switches.

Microkernels run most services in kernel space for speed, while monolithic kernels isolate services in user space for stability.

Containers and VMs both emulate hardware, differing only in whether cgroups or namespaces are used to manage memory.

Containers share the host kernel, using namespaces for isolation and cgroups for resource limits; VMs run full guest OSes.

VMs share the host kernel using namespaces and cgroups, while containers each boot their own full guest OS kernel.

Containers boot a full guest kernel per instance, while VMs use namespaces and cgroups to share the single host kernel.

Cgroups isolate what a process can see, while namespaces limit the resources a process group can consume.

Both namespaces and cgroups isolate the filesystem view, but neither one controls CPU or memory usage limits.

Namespaces isolate what a process can see, while cgroups limit the resources a process group can consume.

Namespaces emulate virtual hardware, while cgroups provide each container with its own separate guest kernel.

Type-1 and Type-2 both run on a host OS; containers replace the kernel entirely with namespaces and full hardware emulation.

Type-1 uses containers and Type-2 uses namespaces; both of these approaches boot a separate guest kernel per application.

Type-1 runs on a host OS and Type-2 runs on bare metal; containers virtualize hardware instead of sharing the host kernel.

Type-1 runs on bare metal and Type-2 runs on a host OS; containers share the host kernel instead of virtualizing hardware.

Layered kernels place everything in one block, modular kernels use strict levels, and hybrid kernels run all services as user processes.

Layered kernels load drivers on demand, modular kernels run entirely in user space, and hybrid kernels remove all layering for pure speed.

Layered kernels stack ordered levels, modular kernels load components at runtime, and hybrid kernels mix monolithic speed with modularity.

Layered kernels run as microkernels, modular kernels compile statically, and hybrid kernels isolate every service in a separate address space.

Running to Waiting on scheduler preemption; Running to Ready when an I/O completes

Running to Waiting when a child process exits; Running to Ready on memory freeing

Running to Waiting when its time slice expires; Running to Ready on a page fault

Running to Waiting on an I/O or event wait; Running to Ready on scheduler preemption

Threads always run slower than processes; both keep fully isolated memory to prevent any data corruption

Threads share the process address space with low overhead; processes have separate memory and cost more

Threads each own a separate address space; processes share one address space with very little overhead

Threads and processes both share memory fully; the only real difference is their scheduling priority level

Process state, program counter, CPU registers, scheduling and memory info, and open-file/I/O status

The full source code of the program plus a copy of every file the process has opened during its run

Just the memory page tables and heap contents, excluding any register or scheduling-related information

Only the process ID and its current priority, with all register state kept solely in the CPU hardware

Heap and global data are private per thread; only the code segment and CPU registers are shared broadly

Code, global data, heap, and open files are shared; stack, registers, and program counter are private

Stack, registers, and program counter are shared; code, heap, and open files are kept private per thread

Everything including the stack and registers is shared; only the thread's priority value stays fully private

A program is passive code on disk, a process is a program in execution, and a thread is an execution path within a process.

A program is code in memory, a process is a scheduled thread, and a thread is a running copy of the program with its own memory.

A program is a group of threads, a process is passive code, and a thread is the active execution of a program stored on disk.

A program is running code, a process is idle code on disk, and a thread is a separate program that shares memory with others.

Threads guarantee faster execution on all hardware but require roughly twice the memory of using separate processes.

Threads always run in parallel on one core and simplify the code by fully isolating any state that gets shared.

Threads remove the need for context switches while eliminating every deadlock and race-condition possibility entirely.

Threads improve responsiveness and resource sharing but add synchronization complexity and race-condition risks.

A zombie is still running without a parent; an orphan finished but leaves an entry until the parent finally calls wait.

A zombie has exited but is unreaped by its parent; an orphan's parent died first, so init adopts it.

A zombie's parent died so init adopts it; an orphan has exited but still holds an uncollected exit status.

A zombie and an orphan both keep running after the parent exits, staying alive until the system reboots and clears them.

After fork the child immediately receives a full private copy of every page, which is shared back if never written.

After fork all pages are copied lazily to disk and returned to memory only when either process reads them.

After fork the child shares writable pages directly, so changes by one process stay visible to the other until exit.

After fork the parent and child share pages read-only; a page is duplicated only when one process writes it.

User threads can run on multiple cores at once; kernel threads are limited to a single core per process

User threads are scheduled by the OS kernel; kernel threads run entirely in user space without any traps

User threads need a system call per switch; kernel threads switch without ever entering the OS kernel

User threads switch fast but one blocking call stalls all; kernel threads cost more but schedule independently

fork() allocates a fresh empty address space; exec() copies the parent's memory into that new child space

fork() shares one address space between parent and child; exec() spawns a brand-new independent process

fork() immediately loads a new program image; exec() merely creates an empty child with no address space

fork() duplicates the parent's address space (copy-on-write); exec() replaces it with a new program image

Threads run entirely in user space, so the kernel scheduler is never involved when switching them

Threads share an address space, so no memory-map or TLB switch is needed on a context switch

Threads use a simpler priority scheme, so the scheduler picks the next one without any bookkeeping

Threads always have smaller stacks, so far less register state must be saved during each switch

When each task needs its own separate address space to run untrusted third-party code more safely

When tasks must frequently share data in memory with low-latency communication and less overhead

When tasks rarely communicate and benefit from full fault isolation across independent process spaces

When tasks must be strongly isolated so one crash can never affect the others sharing the machine

A TCB and a PCB are identical structures, both storing the complete address space and every thread's saved register context.

A TCB holds per-thread state like registers and stack, while a PCB holds per-process state including all its threads and resources.

A TCB stores scheduling priority for the CPU, while a PCB stores the interrupt vector table used by the kernel at boot time.

A TCB holds memory maps and open files, while a PCB holds only the register and stack information belonging to a single thread.

Many-to-one runs threads in parallel, one-to-one blocks all on a syscall, and many-to-many maps each user thread to two kernel threads.

Many-to-one requires no kernel support, one-to-one has no concurrency, and many-to-many maps kernel threads onto a single user thread.

Many-to-one maps one user thread to many kernel threads, one-to-one shares a kernel thread, and many-to-many uses only user threads.

Many-to-one maps many user threads to one kernel thread, one-to-one maps each to a kernel thread, and many-to-many multiplexes many onto fewer.

A system call is compiled into the program, while a library function is resolved by the kernel scheduler at every runtime call.

A system call runs entirely in user space, while a library function always switches to kernel mode to access the hardware directly.

A system call and a library function are identical; both execute in kernel mode and demand exactly the same privilege level.

A system call requests a kernel service via a mode switch, while a library function runs in user space and may wrap a syscall.

An interrupt and a trap are both asynchronous hardware signals; only their assigned priority level distinguishes them at runtime.

An interrupt halts the CPU permanently, like power failure; a trap merely logs an error, like a page fault, and continues.

An interrupt is synchronous from software, like a syscall; a trap is asynchronous from hardware, like a periodic timer tick.

An interrupt is asynchronous from hardware, like keyboard I/O; a trap is synchronous from software, like a divide by zero.

It holds the queue of pending interrupts in order, letting the CPU run all the handlers sequentially without any dispatch.

It stores the saved registers of every interrupted process so the scheduler can later resume them after the handler runs.

It maps each interrupt number to the address of its handler routine so the CPU can dispatch to the correct code.

It lists which hardware devices may interrupt, enforcing priority by blocking any lower-level device signals from firing.

Polling frees the CPU entirely; interrupts require constant checking; DMA repeatedly reads the device registers during each and every block

Polling uses interrupts to notify the CPU; interrupt I/O checks status in a loop; DMA needs the CPU to move each byte during the transfer

Polling has the CPU repeatedly check status; interrupts notify the CPU when ready; DMA moves data to memory without CPU per-byte involvement

Polling moves data via a controller; interrupts poll the device status; DMA notifies the CPU only when the entire transfer buffer is empty

A software trap switches the CPU to kernel mode, runs the handler via the syscall table, then returns to user mode.

The CPU stays in user mode, jumps directly to the kernel function, and returns without any mode switch or trap.

The process is terminated and restarted in kernel mode, where the handler runs before spawning a fresh user process.

A hardware interrupt saves registers to disk, loads the kernel, and copies it into the calling process address space.

Preemptive can forcibly interrupt a running process; non-preemptive lets it run until it blocks or finishes

Preemptive runs each process to completion; non-preemptive interrupts processes at fixed timer intervals always

Preemptive avoids context switches entirely; non-preemptive relies on frequent switching for fair CPU sharing

Preemptive is used only in batch systems; non-preemptive is required for all real-time interactive workloads

Throughput is jobs finished per unit time, turnaround is time to first output, response is submission to completion.

Throughput is submission to completion, turnaround is jobs finished per unit time, response is time to first output.

Throughput is jobs finished per unit time, turnaround is submission to completion, response is time to first output.

Throughput is time to first output, turnaround is jobs finished per unit time, response is submission to completion.

It is preempted when the quantum expires and placed at the front of the ready queue again.

It is terminated when the quantum expires and must be resubmitted to the ready queue later.

It is preempted when the quantum expires and placed at the back of the ready queue.

It is allowed to keep running until completion since the quantum only applies to short jobs.

The CPU is given to the highest-priority ready process; priorities may be set statically by the user or dynamically by the system

The CPU is given to the process with the shortest burst time; priorities are always fixed at process creation and never changed

Processes run strictly in arrival order; priorities are inferred solely from how long each process has been waiting in memory

Each process receives an equal time slice in rotation; priorities only decide which queue a process is initially placed into

Moving a process from disk into memory during swapping; it is overhead because of the slow speed of disk I/O access operations

Switching between kernel and user mode inside one process; it is overhead because the entire main memory must be flushed each time

Saving the state of the running process and loading another's; it is overhead because the CPU does no useful work meanwhile

Changing a process priority in the ready queue; it is overhead because scheduling decisions must be recomputed on every single switch

Low-priority processes may wait indefinitely; aging gradually raises their priority the longer they keep waiting

Processes deadlock waiting for resources; aging preempts the oldest process to release its held locks periodically

High-priority processes block on I/O forever; aging lowers their priority after each completed CPU burst period

The ready queue overflows with new processes; aging removes stale entries exceeding their maximum lifespan value

I/O devices sit idle while the CPU is busy; Round Robin overlaps I/O and CPU by interleaving their phases

Processes convoy around a shared lock; Round Robin gives each a private copy of the resource to avoid contention

Short processes wait behind one long process; Round Robin preempts via time slices so short jobs finish sooner

Long processes wait behind many short ones; Round Robin batches similar jobs together to reduce total waiting time

Queues are ordered strictly by arrival time; a process advances to a higher queue after each I/O completion

All queues share a single time quantum; I/O-bound processes are demoted because they release the CPU too often

Processes move between queues by behavior; CPU-bound ones drop to lower priority while I/O-bound ones stay high

Processes are fixed to one queue by type; CPU-bound ones get the highest priority to finish computations fast

Reducing response time increases throughput because shorter time slices let the CPU complete more total work

Optimizing response time can require frequent preemption, which adds overhead and can lower overall throughput

Maximizing throughput always minimizes turnaround time because more jobs complete within each scheduling window

Improving turnaround time guarantees better response time since both measure the same waiting interval per job

Processes are served by priority each turn; a small quantum raises throughput by reducing the number of switches

Each process gets a slice sized to its burst; a large quantum improves response time while lowering total overhead

Each process runs to completion in order; a large quantum improves response time but starves longer waiting jobs

Each process gets a fixed time slice in turn; a small quantum improves response time but adds switching overhead

Long-term admits new jobs, short-term selects ready processes for CPU, medium-term swaps processes in and out.

Short-term admits new jobs, long-term selects ready processes for CPU, medium-term swaps processes in and out.

Medium-term admits new jobs, short-term swaps processes, long-term selects ready processes for CPU each time.

Long-term swaps processes in and out, medium-term admits new jobs, short-term selects ready jobs for CPU.

In systems running mostly long CPU-bound jobs that must finish as fast as possible.

In interactive time-sharing systems where fair, responsive treatment of all processes matters most.

In batch systems where all process burst times are known accurately in advance beforehand.

In systems whose only goal is minimizing the average waiting time for every job.

Swapping moves processes between memory and disk; the medium-term scheduler swaps out to reduce multiprogramming.

Swapping moves processes between memory and registers; the long-term scheduler swaps out to reduce multiprogramming.

Swapping copies processes from disk to disk; the medium-term scheduler swaps out to increase multiprogramming.

Swapping moves pages between cache and memory; the medium-term scheduler swaps in to raise multiprogramming.

The dispatcher hands CPU control to the chosen process; dispatch latency is the time this switch takes.

The dispatcher admits jobs into memory; dispatch latency is the delay before the scheduler picks a process.

The dispatcher selects which process runs next; dispatch latency is the time a process waits in ready queue.

The dispatcher preempts running processes; dispatch latency is the time a process spends using the CPU here.

SJF is non-preemptive and runs the shortest job fully; SRTF preempts when a shorter job arrives.

SJF and SRTF are identical, but SRTF also considers process priority when a shorter job arrives.

SJF is preemptive and runs the shortest job fully; SRTF is non-preemptive when a shorter job arrives.

SJF picks the longest job first; SRTF preempts the running process when a shorter job arrives later.

Multilevel Queue and Feedback both fix processes permanently, but Feedback adds round robin on top.

Multilevel Queue uses a single shared queue; Multilevel Feedback splits it into several fixed queues.

Multilevel Queue fixes processes to one queue; Multilevel Feedback lets them move between queues.

Multilevel Queue lets processes move between queues; Multilevel Feedback fixes them to one queue.

Two processes competing for CPU cycles so the slower one is starved, like a background job never finishing its full computation

A thread holding a lock too long so others block indefinitely, like a shared counter being frozen at its last written value

Concurrent threads interleaving unsynchronized access so the result depends on timing, like two lost increments to a shared counter

A single thread executing operations out of program order so the result depends on the compiler, like a reordered loop counter

A mutex can only be used across processes; a counting semaphore exists purely to signal completion between a pair of threads

A semaphore always blocks the caller; a counting mutex is used whenever a single shared variable needs atomic increments

A semaphore enforces strict ownership by one thread; a counting mutex is used to allow many threads into one critical section

A mutex enforces ownership for mutual exclusion; a counting semaphore is used to manage access to multiple identical resources

Coordinating shared access so a solution provides atomicity, priority ordering, and starvation freedom under any scheduling policy

Coordinating shared access so a solution provides mutual exclusion, progress, and bounded waiting for all processes

Coordinating shared access so a solution provides deadlock freedom, fairness, and guaranteed constant-time entry for all processes

Coordinating shared access so a solution provides mutual exclusion, preemption, and equal CPU time among competing processes

A spinlock always yields the CPU immediately; a blocking lock keeps polling and is preferred on single-core systems only

A blocking lock busy-waits and suits very short critical sections; a spinlock sleeps the thread and suits longer, contended waits

A blocking lock never involves the scheduler; a spinlock triggers a context switch and is preferred when holding times are long

A spinlock busy-waits and suits very short critical sections; a blocking lock sleeps the thread and suits longer waits

Producers and consumers share a fixed buffer; two mutexes track slot counts while a counting semaphore guards all buffer writes

Producers and consumers share a fixed buffer; empty and full semaphores track slots while a mutex guards buffer access

Producers and consumers alternate strictly; the empty and full semaphores replace any mutex since only one thread ever runs at once

Producers and consumers share an unbounded buffer; a single binary semaphore both counts items and enforces mutual exclusion alone

wait() decrements the count and signal() increments it; they must be atomic so concurrent updates never corrupt the value.

wait() increments the count and signal() decrements it; atomicity ensures a process always blocks before it enters.

wait() blocks all threads and signal() wakes them; atomicity is only needed on single-core uniprocessor systems.

wait() and signal() both increment the count; atomicity guarantees fairness among all the waiting processes.

A monitor bundles shared data with procedures under mutual exclusion; condition signal() has no memory, unlike a counting semaphore.

A monitor is just a semaphore initialized to one; condition wait() and signal() behave identically to semaphore operations.

A monitor is a low-level lock over shared data; condition wait() never blocks, unlike a counting semaphore's operation.

A monitor replaces the kernel scheduler entirely; condition signal() always increments a stored counter, exactly like a semaphore.

It uses a single lock variable for two processes; it assumes a hardware Test-and-Set instruction is always available.

It uses flag[] and turn for many processes; it assumes a priority scheduler that never preempts a running process.

It uses flag[] and turn for two processes; it assumes atomic reads/writes and no reordering of instructions.

It uses turn alone for two processes; it assumes disabling of interrupts around each entry to the critical section.

They disable all interrupts during memory access, letting only one core run inside the critical section at a time.

They flush the CPU cache before each access so every thread reads the freshest copy of the lock variable.

They rearrange the memory bus priorities so higher-priority threads always win the lock during contention.

They read and modify a memory word in a single atomic step, letting locks be acquired without race conditions.

Philosophers share forks and deadlock if all grab one side; solutions include resource ordering or limiting concurrent diners.

Philosophers share plates and starve if any eats too fast; solutions include raising the priority of only the hungry philosophers.

Philosophers share forks and deadlock only on uniprocessors; solutions include running each philosopher on a dedicated core.

Philosophers share a single fork and livelock repeatedly; solutions include disabling all preemption while a philosopher eats.

A medium-priority task preempts the scheduler queue; inheritance suspends all lower tasks until the medium one fully completes execution

Two equal tasks deadlock on a shared lock; inheritance swaps their priorities so one can proceed and release the contested resource

A high-priority task starves a low-priority one holding a lock; inheritance permanently lowers the high task's priority to restore balance

A low-priority task holding a lock blocks a high-priority one; inheritance temporarily raises the holder's priority to release it sooner

Only one reader and one writer may proceed at a time; reader-preference improves throughput while writer-preference eliminates all waiting

Many readers may share access but writers need exclusion; reader-preference can starve writers, and writer-preference can starve readers

Many writers may share access but readers need exclusion; reader-preference always deadlocks, while writer-preference guarantees fairness

Readers and writers must strictly alternate turns; reader-preference reduces latency, while writer-preference removes the need for locks

Resource sharing, hold and wait, forced preemption, and linear waiting must all hold simultaneously.

Mutual exclusion, priority inversion, preemption allowed, and circular wait must all hold simultaneously.

Mutual exclusion, starvation, no preemption, and bounded waiting must all hold simultaneously.

Mutual exclusion, hold and wait, no preemption, and circular wait must all hold simultaneously.

Deadlock denies one process resources; livelock blocks all pairs mutually; starvation keeps threads spinning without any progress.

Deadlock blocks processes waiting on each other; livelock keeps them active without progress; starvation denies one indefinitely.

Deadlock blocks a single process indefinitely; livelock crashes it; starvation lets every process eventually finish its own work.

Deadlock keeps processes busy without progress; livelock blocks them forever; starvation halts the whole system permanently.

A graph of processes and resources where a cycle may indicate a deadlock.

A graph of memory pages where an edge marks that a page fault occurred.

A table mapping each running process to the CPU time it now requires.

A tree of threads where a leaf node marks a process that is starving.

Prevent deadlocks by forcing each process to lock its resources in a fixed order.

Avoid deadlocks by running the Banker's Algorithm before each new allocation.

Detect deadlocks quickly and then abort the youngest of the waiting processes.

Ignore deadlocks entirely because they are rare and prevention is costly.

Prevention relies on timeouts to recover; avoidance rolls back threads, and Banker's grants a request strictly in arrival order.

Prevention allocates all resources upfront; avoidance kills processes early, and Banker's grants a request only to the oldest process.

Prevention breaks a necessary condition; avoidance uses runtime info, and Banker's grants a request only if a safe sequence remains.

Prevention detects cycles after they form; avoidance ignores resources, and Banker's grants a request only after preempting a holder.

It grants requests only when total demand is below the free physical memory.

It checks whether a sequence exists in which every process can finish safely.

It denies any request that would leave a single resource type fully allocated.

It detects cycles in the resource graph and then rolls a chosen process back.

The OS prevents every cycle up front by strictly ordering all resource requests.

The OS runs a detection algorithm periodically and recovers by killing or preempting.

The OS ignores the condition and reboots whenever the whole system becomes slow.

The OS requires each process to declare its maximum needs before it can start.

An abstraction mapping each process's address space across RAM and disk, so only actively used pages stay in RAM while the rest reside on disk until needed.

A scheduler feature that runs a large program in small time slices, loading each function only while it executes and discarding it fully once the call returns.

A technique that compresses the process's data in RAM on the fly, so a program needing more memory than exists can be squeezed into the available physical frames.

A dedicated fast region of the disk that the CPU addresses directly, so large programs execute their instructions straight from disk without ever occupying RAM.

An abstraction giving each process a large private address space, freeing the programmer from managing physical memory and providing isolation between processes.

A caching layer between CPU and RAM that automatically speeds up memory access, so the programmer can rely on faster loads without tuning any data structures.

A compiler optimization that reduces a program's memory footprint at build time, so the programmer no longer needs to worry about how large the data set becomes.

A hardware feature that lets several programs share the same physical addresses safely, so the programmer can write code that reads other processes' memory.

A queue of pending page faults that the handler then resolves in order.

A table of free frames that the allocator scans on every allocation.

A buffer of recent disk blocks that avoids re-reading them from disk.

A cache of recent page translations that avoids walking the page table.

Excessive paging where the CPU spends more time swapping pages than executing.

Excessive context switching where the scheduler runs far more often than the tasks.

Excessive locking where threads spend more time blocked and waiting than executing.

Excessive fragmentation where free memory holes grow far faster than they merge.

Internal scatters free holes (paging); external wastes space inside blocks (contiguous).

Internal and external both waste the unused space left inside each allocated block.

Internal wastes space inside blocks (paging); external scatters free holes (contiguous).

Internal wastes space inside blocks (contiguous); external scatters free holes (paging).

Both paging and segmentation use fixed frames; combining them mainly shrinks the page table.

Paging uses logical units; segmentation uses fixed frames; combining removes internal fragmentation.

Both paging and segmentation use logical units; combining them mainly speeds up TLB lookups.

Paging uses fixed frames; segmentation uses logical units; combining removes external fragmentation.

A trap raised when a referenced page is not in RAM; the OS finds it on disk, loads it into a free frame, updates the page table, and restarts the instruction.

A signal raised when RAM is entirely full; the OS swaps the whole running process out to disk, schedules another process, and later reloads the full image.

An interrupt raised when the CPU cache misses; the OS reloads the missing cache line from main memory, updates the tag bits, and resumes the current instruction.

An error raised when a process references an invalid address; the OS immediately terminates that process and reclaims every memory page it had been allocated.

Physical addresses are generated by the program, logical addresses name actual RAM locations, and the MMU translates physical to logical addresses at runtime.

Logical and physical addresses are always identical, and the MMU exists only to check access permissions and raise faults whenever a protected region is touched.

Logical addresses are generated by the program, physical addresses name actual RAM locations, and the MMU translates logical to physical addresses at runtime.

Logical addresses are used by disk storage, physical addresses by the CPU cache, and the MMU merely buffers pending memory writes before they reach main memory.

It splits memory into variable-size segments matched to program modules, so the OS can always find a contiguous hole large enough for each incoming request.

It periodically relocates all allocated blocks toward one end of memory, so scattered free regions are merged into a single large contiguous free area.

It keeps each process in one contiguous region but swaps idle ones to disk, so freed space is reused before fragmentation can build up across memory.

It splits memory into fixed-size frames and pages, so any free frame can hold any page and processes need not occupy contiguous physical memory.

FIFO evicts the oldest resident page and is guaranteed to produce the minimum number of page faults.

LRU evicts the page whose next use is farthest in the future, requiring prediction of future references.

Optimal evicts the page whose next use is farthest in the future, requiring knowledge of future references.

Optimal evicts the least recently used page, requiring a complete log of every past reference.

Compile-time binds relocatable code, load-time fixes final addresses, execution-time needs no hardware support at all.

Compile-time binds if the location is known then, load-time binds relocatable code, execution-time allows runtime moves.

Compile-time needs a base register, load-time binds absolute code, execution-time binds before the program starts.

Compile-time binds only at run, load-time binds during linking, execution-time binds when the source is written.

It swaps idle processes to disk to free frames, reducing the page-fault rate under heavy load.

It shifts allocated partitions together to merge scattered free holes, reducing external fragmentation.

It splits large partitions into fixed blocks to cut internal fragmentation within contiguous memory.

It merges adjacent page tables into one region to lower the overhead of address translation.

They stream a file through a socket so it is accessed remotely without buffering it in user space.

They pin a file entirely in the TLB so repeated accesses skip both paging and the disk controller.

They map a file into the address space so it is accessed via memory, avoiding explicit I/O calls.

They copy a file into a kernel buffer so it is accessed via faster block reads instead of syscalls.

It scans frames using a dirty bit, clearing set bits to give a second chance, evicting clean pages.

It scans frames using a reference bit, clearing set bits to give a second chance, evicting bit 0.

It timestamps each frame on access and evicts the frame holding the oldest recorded access time.

It counts references per frame and evicts the page with the smallest count on each replacement scan.

Adding more frames always decreases page faults; FIFO suffers thrashing only, while LRU avoids it entirely because it evicts the least frequently referenced page.

Removing frames can decrease page faults; FIFO tracks load order, but LRU uses reference counts and therefore avoids the paradox by counting every page access.

Adding more frames can increase page faults; FIFO evicts by recency, but LRU keeps the oldest pages resident so its resident set always grows with more frames.

Adding more frames can increase page faults; FIFO ignores usage, but LRU is a stack algorithm whose resident set for n frames is a subset of that for n+1.

LRU evicts the oldest-loaded page and can show Belady's Anomaly, where more frames raise faults; FIFO evicts the least-recently-used page and never exhibits it.

FIFO evicts the oldest-loaded page and can show Belady's Anomaly, where more frames raise faults; LRU evicts the least-recently-used page and never exhibits it.

Both FIFO and LRU evict the least-recently-used page; Belady's Anomaly is the case where adding more frames unexpectedly reduces the number of page faults.

FIFO evicts the most-recently-used page and LRU the oldest; Belady's Anomaly is when both algorithms fault on the same reference string regardless of frame count.

It maps physical frames to virtual pages; multi-level tables exist chiefly to store extra permission bits that a flat table has no room to represent at all.

It maps virtual pages to physical frames; multi-level tables are used purely to make address translation faster by reducing the number of memory lookups.

It maps virtual pages to physical frames; multi-level tables allocate only the portions actually used, avoiding one huge contiguous table for the whole space.

It maps disk blocks to physical frames; multi-level tables are needed so several processes can safely share a single global table without any locking overhead.

The working set is the pages loaded at startup; the window sets how many frames each process is given.

The working set is the pages a process will reference next; its window fixes the overall page-fault rate.

The working set is the pages modified since load; the window limits the number of dirty pages retained.

The working set is the pages referenced in a recent window; summing their sizes estimates total memory demand.

A two-level table that caches recent translations so the TLB miss penalty is greatly reduced overall.

A single table with one entry per virtual page, shared by all processes to speed address translation.

A single table with one entry per physical frame, shared by all processes to cut table memory use.

A per-process table indexed by frame number that stores each page's disk location for faster swapping.

EAT = h×mem + (1−h)×(TLB + 2×mem), where h is the TLB hit ratio.

EAT = h×TLB + (1−h)×(TLB + 2×mem), where h is the TLB hit ratio.

EAT = h×(TLB + 2×mem) + (1−h)×(TLB + mem), where h is the TLB hit ratio.

EAT = h×(TLB + mem) + (1−h)×(TLB + 2×mem), where h is the TLB hit ratio.

LFU replaces the page with the smallest use count; MFU replaces the one with the highest count.

LFU replaces the page unused for longest; MFU replaces the page most recently accessed here.

LFU replaces the largest resident page; MFU replaces the smallest resident page in memory.

LFU replaces the oldest resident page; MFU replaces the most recently loaded page in memory.

It measures each process's fault rate and swaps out the one showing the lowest rate observed.

It counts total faults per second and halts new process creation once a threshold is crossed.

It fixes a constant number of frames per process and blocks any process exceeding its rate.

It sets upper and lower fault-rate bounds, adding frames when high and removing them when low.

Global lets a process take frames from any process; local restricts it to its own frame set.

Global fixes frames at process creation; local adjusts them dynamically based on fault rates.

Global divides frames equally among all processes; local gives frames based on process priority.

Global assigns frames by process size; local assigns them by each process's arrival order.

A two-level directory arranges all directories into one hierarchical parent-child tree

A tree directory permits files to be shared through multiple links between users

A single-level directory gives each user a private directory to isolate their files

An acyclic-graph structure allows shared subdirectories and files but forbids cycles

Indexed access always processes records strictly in order from the start of the file

Sequential access jumps to any record instantly using a stored block position value

Direct access reads or writes any block by its number without processing prior blocks

Direct access rebuilds a separate index block whenever a record is added or removed

It holds the filename and directory path, but not the permissions or the data-block pointers.

It holds file metadata and data-block pointers, but not the filename or the file contents.

It holds the data-block pointers and filename, but not the file size or the last-access time.

It holds the file contents and permissions, but not the ownership or the timestamp details.

Both store a pathname, so deleting the original always leaves a dangling link that cannot resolve.

Both share the same inode, so deleting the original always leaves the file fully accessible still.

A hard link shares the inode so the file survives; a soft link breaks if the target is deleted.

A hard link points to a pathname and breaks; a soft link shares the inode so the file survives.

It is a per-file lock that the OS uses to serialize all concurrent access from multiple processes.

It is a kernel buffer holding file data that maps process memory onto the disk blocks of the file.

It is a per-process integer index into a table that references the system-wide open-file table.

It is a system-wide integer that directly stores the file's inode and its current read/write offset.

A bit vector records only allocated blocks, while a linked list records only free ones

A bit vector chains free blocks in a list, while a linked list uses one bit per block

A bit vector uses one bit per block, while a linked list chains free blocks together

Both approaches store one pointer per allocated block inside a fixed table on disk

A table storing one index block per file that lists all of that file's blocks

A bitmap marking which blocks are free and which are currently in use on disk

A table where each entry points to the next block, forming a chain per file

A table recording the starting block and total length of each contiguous file

It splits a physical disk into partitions and assigns each one a drive letter

It copies the entire contents of the device into memory for faster file access

It formats the target device and creates a fresh empty file system structure

It attaches a file system at a mount point and reads its metadata for access

It periodically snapshots the whole disk, so the file system can roll back to the last saved image.

It logs pending changes before committing them, so the log can be replayed to restore consistency.

It caches all writes in memory until shutdown, so pending changes are flushed only when it is safe.

It mirrors every disk block to a backup device, so lost data can be copied back after a crash.

All three offer identical random-access speed; only their disk fragmentation behavior differs strongly overall.

Linked gives the fastest random access; contiguous suits sequential only; indexed wastes the most disk space.

Indexed gives the worst random access; contiguous needs no index; linked avoids all fragmentation issues here.

Contiguous gives the fastest random access; linked suits sequential only; indexed allows it with overhead.

A cache holding recently accessed disk blocks to speed up all file read operations

A partition table describing where each mounted file system resides on the disk

A tool that converts one on-disk file system format into another compatible format

An abstraction layer providing a uniform interface to many different file system types

Both named and unnamed pipes persist on disk and survive after the processes exit

A named pipe has a file-system name and works between unrelated processes

A named pipe allows only one-way data flow, while an unnamed pipe is bidirectional

An unnamed pipe has a file-system name and works between unrelated processes

A named disk file both processes open by path, taking turns to append and truncate its contents freely.

A kernel-managed byte buffer that the child inherits, letting one end write while the other reads.

A shared memory region both processes map directly, using locks to coordinate reads and writes safely.

A network connection between the two processes that routes bytes through the local loopback interface.

Message passing is faster but harder to synchronize; shared memory is simpler but slower

Shared memory is slower because every access requires a system call to the kernel

Both are equally fast, but message passing needs no kernel involvement to send data

Shared memory is faster but harder to synchronize; message passing is simpler but slower

Blocking calls that pause a process until another process explicitly wakes it with matching data content.

Structured messages placed on a queue that processes read in order, carrying arbitrary user payload data.

Shared counters incremented by the kernel that processes poll to detect events happening in the system.

Asynchronous software interrupts that notify a process of events, carrying only a predefined signal number.

Shared files mapped into memory that processes edit together while the kernel serializes each write access.

Read-only channels the kernel creates so a server can broadcast fixed status data to many clients at once.

Bidirectional endpoints identified by descriptors that let processes exchange bytes locally or over a network.

Signal-based handshakes where processes swap short numeric codes to synchronize their execution steps closely.

A user library applications link against to bypass the kernel and control the hardware registers directly.

Firmware stored on the device that boots it and exposes a fixed menu of operations to any operating system.

Software that translates generic OS I/O requests into commands specific to a particular hardware device.

A kernel thread that schedules which process may access each device based on their current priority levels.

Polling checks status in a loop; interrupts notify the CPU, and polling wins when devices respond very fast.

Polling relies on DMA while interrupts rely on the scheduler, and polling wins when many devices are attached.

Polling uses hardware lines while interrupts use software flags, and polling wins on slow, rarely-ready devices.

Polling blocks the CPU entirely while interrupts run concurrently, and polling wins for background batch transfers.

It caches recent transfers inside the device controller so the CPU can reread data without new bus cycles.

It lets devices transfer data directly to and from memory, freeing the CPU from copying each byte itself.

It schedules device transfers by priority in the kernel, letting the CPU overlap I/O with unrelated computation.

It compresses data on the device before sending it to memory, so the CPU processes fewer bytes overall later.

Blocking reads whole files; non-blocking reads chunks; async reads randomly wherever the disk head sits nearest.

Blocking waits until done; non-blocking returns immediately; async starts work and notifies on completion later.

Blocking needs DMA; non-blocking needs polling; async needs a dedicated core reserved just for pending requests.

Blocking uses threads; non-blocking uses processes; async uses interrupts to move data without any kernel help.

Buffering encrypts data in transit, like HTTPS; spooling compresses stored files, like archiving old logs safely.

Buffering smooths speed mismatch during transfer, like video playback; spooling queues jobs, like printing.

Buffering caches disk reads, like page cache; spooling mirrors data to backups, like nightly database snapshots.

Buffering queues full jobs for a device, like printing; spooling smooths byte rates, like streaming a video.

Buffering permanently stores files on the disk, while caching schedules the order in which pending I/O requests are serviced.

Buffering smooths speed and size mismatches between devices, while caching keeps copies of data for faster repeat access.

Buffering encrypts data moving to devices, while caching compresses that data to reduce the total disk space it consumes.

Buffering allocates virtual memory pages to processes, while caching maps device registers into the kernel's protected address space.

RAID 0 gives full redundancy, RAID 1 gives distributed parity, and RAID 5 stripes plainly for maximum write speed.

RAID 0 stripes with dual parity, RAID 1 stripes without parity, and RAID 5 mirrors data across every member drive.

RAID 0 stripes with no redundancy, RAID 1 mirrors for full redundancy, and RAID 5 stripes with distributed parity.

RAID 0 mirrors for redundancy, RAID 1 stripes for speed only, and RAID 5 stores a single dedicated parity disk.

SSDs have large seek latency and need frequent defragmentation, so head-movement scheduling matters far more than HDDs.

SSDs and HDDs behave identically to the OS, so both require the same disk-scheduling, defragmentation, and wear policies.

SSDs cannot be partitioned or use file systems, so the OS must access them purely as raw sequential block streams.

SSDs have no seek latency and need wear-leveling and TRIM, so head-movement scheduling matters far less.

It serves the request farthest from the head position, so close requests can be starved indefinitely over time.

It sweeps the head fully across the disk each pass, so the newest arriving requests can be starved indefinitely.

It serves the request closest to the current head position, so distant requests can be starved indefinitely.

It serves requests in strict arrival order, so nearby requests can be starved while the head sweeps far away.

SCAN and LOOK sweep one direction only; C-SCAN and C-LOOK reverse midway; all four always reach the disk end first.

LOOK and C-LOOK reverse at the last request; SCAN and C-SCAN go to the disk end; C-variants sweep one direction.

SCAN and C-SCAN stop at the last request; LOOK and C-LOOK go to the disk end; C-variants ignore movement direction.

All four pick the closest request first; the C-variants add priority queues while LOOK and SCAN use arrival order only.

A reserved area on the disk that stores overflow file data when physical RAM is exhausted during heavy I/O.

A per-process memory region that holds open file descriptors and metadata to speed up path-name lookups only.

An in-RAM cache of file data that serves reads and writes without touching disk, reducing slow device access.

A hardware buffer inside the disk controller that reorders pending I/O requests to minimize total seek time.

Grant rights only to the kernel itself; ACLs schedule CPU time per object, and capabilities are quotas assigned to devices.

Grant each subject only the rights it needs; ACLs list permissions per object, and capabilities are tokens held by subjects.

Give each subject maximum rights for speed; ACLs encrypt objects at rest, and capabilities are backup copies kept on disk.

Grant every subject full rights by default; ACLs record login times per object, and capabilities are passwords held by users.

An RTOS optimizes fair CPU sharing; hard deadlines are averaged over time and soft deadlines must never be missed

An RTOS runs without any scheduler; hard means single-core execution while soft means multi-core parallel execution

An RTOS maximizes total throughput; hard deadlines apply to kernel tasks and soft deadlines apply to user tasks alone

An RTOS guarantees deterministic timing; hard deadlines cause failure if missed, soft ones only degrade quality

An RTOS prioritizes predictable response; its scheduler is preemptive and priority-driven to guarantee deadlines

An RTOS prioritizes maximum throughput; its scheduler dynamically ages processes to boost long-waiting background jobs

An RTOS prioritizes user interactivity; its scheduler uses round-robin time slices to share the CPU evenly across all

An RTOS prioritizes energy savings; its scheduler batches tasks together and defers them to reduce total context switches

Rows are objects and columns are domains; ACLs store each row, while capability lists store each column of the matrix

Rows are processes and columns are threads; ACLs store the whole matrix, while capability lists store a hashed summary

Rows are domains and columns are objects; ACLs store each column, while capability lists store each row of the matrix

Rows are users and columns are files; ACLs store the diagonal entries, while capability lists store off-diagonal entries