lOMoARcPSD|61528447

UNIT 1 TO 7 OS Notes PDF

Network technology (Madras Institute of Technology, Anna University)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

L T P C
CP25C03 Advanced Operating Systems
3 0 0 3
Course Objectives:
 To analyze the architectures and design issues of advanced operating systems.
 To develop the model for process synchronization and recovery in complex
environments.
 To evaluate algorithms for distributed coordination, resource management, fault
tolerance, and security.

Advanced Process and Thread Management: Multithreading models, thread pools,

context switching, Synchronization issues and solutions: semaphores, monitors, lock-free
data structures, CPU scheduling in multi-core systems
Activity: CPU scheduler simulation for multicore systems.

Memory and Resource Management in Modern OS: Virtual memory, demand paging,
page replacement policies-Huge pages, NUMA-aware memory management-Resource
allocation in cloud-native environments
Activity: Simulate demand paging and page replacement algorithms.

Virtualization and Containerization: Hypervisors (Type I & II), KVM, QEMU, Xen-
Containers: Docker, LXC, systemd-nspawn-OS-level virtualization and namespaces
Activity: Deploy and configure Docker containers with various images.

Distributed Operating Systems and File Systems: Distributed scheduling, communication,

and synchronization-Distributed file systems: NFS, GFS, HDFS- Transparency issues and
fault tolerance
Activity: Simulate distributed process synchronization.

Security and Trust in Operating Systems: Access control models: DAC, MAC, RBAC-OS
hardening techniques, sandboxing, SELinux, AppArmor-Secure boot, rootkit detection,
trusted execution environments
Activity: Implement Role-Based Access Control (RBAC) using Linux user and group
permissions.

Real-Time and Embedded Operating Systems: Real-time scheduling algorithms (EDF,

RM)-POSIX RT extensions, RTOS architecture-TinyOS, FreeRTOS case studies
Activity: Analyze FreeRTOS task scheduling behavior.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

UNIT 1 ADVANCED PROCESS AND THREAD MANAGEMENT

Advanced Process and Thread Management: Multithreading models, thread pools, context switching,
Synchronization issues and solutions: semaphores, monitors, lock-free data structures, CPU scheduling in
multi-core systems
Activity: CPU scheduler simulation for multicore systems.

[Link] Models
Multithreading models define the relationships between user-level and kernel-level threads, providing
different trade-offs in performance, flexibility, and complexity.
 Kernel Thread: A thread that is directly known and managed by the operating system kernel. The kernel
schedules kernel threads onto CPU cores.
 User-level Thread: A thread that is managed entirely by a thread library at the user level, without kernel
support.
Many-to-One Model - Multiple user-level threads are mapped to a single kernel-level thread.
Advantages:
 Thread management is done entirely in user space, making it efficient and fast.
 This model is portable and can be implemented on any operating system that supports threads.
Disadvantages:
 The entire process blocks if one thread makes a blocking system call because only one kernel thread
is active at a time.
 It cannot take advantage of multiprocessor architectures as only one thread can run at a time.
Examples: Some early implementations of user-level thread libraries.
One-to-One Model - Each user-level thread is mapped to a separate kernel-level thread.
Advantages:
 Allows true parallelism on multiprocessor systems.
 If one thread blocks, other threads continue to run.
Disadvantages:
 Creating a user thread requires creating a corresponding kernel thread, causing overhead.
 The operating system limits the number of threads.
Examples: Windows, Linux, macOS.
Many-to-Many Model - Multiple user-level threads are mapped to an equal or smaller number of kernel-
level threads.
Advantages:
 Combines benefits of many-to-one and one-to-one models.
 Multiple user threads can run in parallel on multiprocessors.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Blocking system calls by one thread does not necessarily block the process.
 The number of kernel threads can be dynamically adjusted.
Disadvantages:

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 More complex to implement.

Fig: Multithreading models: relationship between user and kernel threads

Examples: Some versions of Solaris, IRIX, and Tru64 UNIX.

Many-to-One (User-Level) One-to-One (Kernel- Many-to-Many (Hybrid)

Level)

Thread User-level thread: Fast, in User-level thread & kernel User-level thread: Fast, in
Generation user space. thread: Created together user space.
via syscall (slower).
Kernel thread: One per Kernel thread: Pool created
process. via syscalls.

Does the None. Sees only a single- Full. Manages every thread Partial. Manages the pool of
kernel know? threaded process. individually. KLTs, not the ULTs.

Blocking Blocks entire process. Blocks only that thread. Library can schedule around
Calls it.

Parallelism None. (Runs on one core). Yes. (True parallelism on Yes. (Parallelism up to the
multiple cores). kernel thread pool size).

Scalability High (for number of user Low (limited by kernel Very High (best for many
level threads), but resources). threads).
ineffective.

2. Thread pools
A thread pool is a collection of pre-created, reusable threads maintained to execute tasks, to reduce the
overhead of frequent thread creation and destruction.

Fig. Thread pool with 2 pre-created threads

Worker Threads  Pre-created threads executing user tasks

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Task Queue  A queue storing tasks awaiting execution

Dispatcher thread  A special thread for monitoring the task queue, assigning tasks to idle worker threads.
Pool Manager  Schedules tasks and adjusts pool size
Working:

1. Tasks are enqueued into the task queue.

2. Idle threads fetch tasks from the queue.
3. Threads perform tasks and return to the pool when done.
4. If all threads are busy, tasks wait in the queue.
Implementation:
initialize thread_pool with N threads
while True:
if task arrives:
enqueue task to task_queue
for thread in thread_pool:
if thread is idle:
dequeue task from task_queue and assign to thread
Design issues:
Pool Sizing
 Fixed Size: Predefine max/min number of threads. Well-suited for predictable workloads.
Too small → CPU underutilization.
Too large → Context switching overhead, memory pressure.
 Dynamic Size: Thread pool grows/shrinks based on demand. Complex implementation.
Task Scheduling
 FIFO Queue: Tasks processed in arrival order (commonly used).
 Priority Queues: Higher-priority tasks processed first (used in some OS/runtime systems).
 Bounded vs. Unbounded Queue: An unbounded queue can lead to out-of-memory errors under heavy
load. A bounded queue can force the task submitter to block or reject tasks when full, providing
backpressure.
Use Cases: Web Servers handling multiple client HTTP requests.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Fig. A multithreaded web server

Limitations:
Deadlocks: Tasks waiting for other tasks inside the same pool.
Starvation: Long tasks blocking short tasks.

Fig. A word processor with three threads

3. Context switching
Context switching is the process by which the CPU stops running one process/thread, saves its current state,
and loads the saved state of another process/thread.

It is best suited for multitasking, multiprogramming, and time-sharing OS. It also prevents the CPU from
staying idle when a process waits for I/O.

For Processes:
1. Save current process state to Process Control Block (PCB)
2. Update process state (running → ready/blocked)
3. Select next process to run
4. Restore new process state from its PCB
5. Update memory management structures

For Threads:
1. Save thread state to Thread Control Block (TCB)
2. Threads share same memory space (faster switching)
3. Only CPU registers, stack pointer, and program counter saved/restored
4. No memory map changes required

Components of a PCB/Context
 Process State: Running, ready, waiting, blocked, etc.
 Program Counter (PC): The address of the next instruction to execute.
 CPU Registers: Contents of all registers.
 CPU Scheduling Information: Process priority, pointers to scheduling queues.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Memory Management Information: Base/limit register values, page tables, segment tables.
 Accounting Information: CPU time used, real-time clock, time limits.
 I/O Status Information: List of I/O devices allocated to the process, list of open files.
Context Switch Time = High overhead (no useful computation).
When switching processes, the data in the CPU cache and Translation Lookaside Buffer (TLB) is for the old
process. The new process will likely require different data and memory mappings, resulting in cache
misses and TLB flushes, which significantly slow down initial memory access.

4. Synchronization issues and solutions: semaphores, monitors, lock-free data structures

Synchronization ensures that multiple processes/threads access shared resources safely without conflicts. It
provides the orderly execution of cooperating processes/threads that share resources. Without proper
synchronization, concurrent access to shared data can lead to data inconsistency and race conditions.
 Critical section: It is a code segment where a process/thread accesses a shared resource. Only one process
should execute in its critical section at any given time.
do {
entry section // Request permission
critical section // Access shared resource
exit section // Release permission
remainder section // Other work
} while (true);
Requirements for Critical Section Solutions:
1. Mutual Exclusion: Only one process in critical section
2. Progress: If no process is in critical section, selection cannot be postponed
3. Bounded Waiting: Limit on how long a process waits
 Race condition: A race condition occurs when two or more processes or threads access and modify the
same data at the same time, and the final result depends on the order in which they run. Without proper
coordination, this can lead to incorrect or unpredictable results.
 Deadlock: Processes wait indefinitely for resources held by each other.
 Starvation: Some processes never get CPU or resource access.
 Priority Inversion: Lower-priority task holds a lock needed by higher-priority tasks.

Classic synchronization problems:

1. Producer–Consumer Problem (Bounded Buffer Problem)
A producer generates items and puts them into a buffer. A consumer takes items from the buffer.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Synchronization Problem:
o Producer must wait if buffer is full.
o Consumer must wait if buffer is empty.
 Solution: Semaphores or mutex + condition variables.
2. Readers–Writers Problem
Multiple readers can read a shared resource at the same time.
Writers need exclusive access (no reader/writer allowed simultaneously).
 Synchronization Problem:
o Ensure no conflict between read and write.
o Handle fairness (avoid starvation of writers/readers).
 Solution: Read–Write locks, semaphores.
3. Dining Philosophers Problem
Five philosophers sit around a table with five forks. Each needs two forks to eat.
 Synchronization Problem: If each philosopher picks one fork, they all starve → deadlock.
 Solution: Avoid circular wait (enforce an order in fork picking).

Synchronization solutions

Software solution: Peterson’s Algorithm

Assumption: N=2 (number of processes)
Two shared variables:
 turn: Integer variable (0 or 1)  Indicates whose turn it is to enter the critical section.
o turn = 0 means Process 0 gets priority
o turn = 1 means Process 1 gets priority

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 flag[2]: Boolean array  flag[i] = true → Process i wants to enter critical section.
o flag = true means Process 0 wants to enter
o flag = true means Process 1 wants to enter
do {
flag[i] = true; // Pi want to enter
turn = j; // HUMBLE Ask Pj to enter

while (flag[j] && turn == j); // Wait if other process also wants to enter and it's their turn
// CRITICAL SECTION - Only one process here
flag[i] = false; // Current process finished, others can enter
// REMAINDER SECTION
} while (true);
Example with Process P0 and P1
Scenario 1: Only Process 0 wants to enter
1. Process 0: flag = true, turn = 1
2. Process 0 checks: flag && turn == 1?
 flag = false (Process 1 doesn't want to enter)
 Condition is false, so Process 0 enters immediately
Scenario 2: Both processes want to enter simultaneously
1. Process 0: flag = true, turn = 1
2. Process 1: flag = true, turn = 0
3. Process 0 checks: flag && turn == 1?
 flag = true but turn = 0 (not 1)
 Process 0 enters
4. Process 1 checks: flag && turn == 0?
 flag = true and turn = 0
 Process 1 waits until Process 0 finishes
Peterson's Algorithm satisfies all requirements for a critical section solution: Mutual Exclusion, Progress and
Bounded Waiting.
Semaphores
Semaphores are synchronization solutions that use atomic operations to control access to shared resources
(critical section) by maintaining a counter. Process/threads acquire (decrement) or release (increment) the
semaphore.
A semaphore S is an integer variable accessed only through two atomic operations:
 wait() (also called P or down)  Decrements the counter
o If the counter becomes negative, the calling process/thread blocks until it can proceed

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 signal() (also called V or up)  Increments the counter

o If the counter was negative (process/threads waiting), wakes one of them
wait(S) or P(S): signal(S) or V(S):
wait(S) { signal(S)
while (S <= 0) { S++;
; // busy wait }
S--;
}
Note: Operations must be atomic to prevent race conditions.
Types of Semaphores:
1. Counting Semaphore: The value S can be any integer (≥ 0). Used to control access to a resource with a
finite number of instances (e.g., a buffer pool with 10 slots in in Producer-Consumer problem).
2. Binary Semaphore (Mutex Lock): The value S can only be 0 or 1. Used to enforce mutual exclusion for
a single instance of a resource protecting a critical section. Acts like a lock: 1 → resource available and 0
→ resource unavailable
semaphore mutex = 1; // Binary semaphore
do {
wait(mutex); // Decrement: mutex becomes 0; proceed
// Critical Section
signal(mutex); // Increment: mutex becomes 1; if a thread is waiting, wake it
// Remainder Section
} while (true); // If mutex is 0, Thread B blocks; when A signals, mutex=1 and B proceeds

Monitors
A high-level synchronization construct that encapsulates shared data and its associated operating procedures.
Provides mutual exclusion and condition variables for signaling between threads. A monitor contains:
1. Shared Variables: Data accessed by multiple threads.
2. Procedures (Methods): Operations on shared variables.
3. Condition Variables: Allow processes to wait for certain conditions before proceeding.
Condition Variables: Used within monitors to allow threads to wait for specific conditions to become true.
Threads block on condition variables and are awakened by other threads once conditions are met. Condition
variables c allows threads to wait within a monitor until a particular condition holds.
 wait(c): Atomically release monitor lock, suspend thread on c
 signal(c): Resume one thread waiting on c
 broadcast(c): Resume all threads waiting on c
Condition variables are not semaphores. It does not increment a counter; it simply wakes a waiting process.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Semaphores Monitors
Abstraction Level Low-level primitive High-level language construct
Mutual Exclusion Programmer-managed, error-prone Compiler-enforced, automatic and safe
Data No; data and sync mechanism are Yes; shared data and procedures are
Encapsulation separate bundled
Mechanism Integer value (S) with wait/signal Condition variables with wait/signal

5. Lock-free data structures

Lock-free data structures enable concurrent access without using mutual exclusion locks, relying instead on
atomic hardware instructions. It allows multiple threads to make progress without ever blocking each other.
Compare-and-Swap (CAS)
CAS atomically compares a memory location to an expected value and, only if equal, swaps it with a new
value.
CAS(addr, expected, new_val)
// if *addr == expected, set *addr = new_val and return true
// else, return false
Test-and-Set (TAS)
TAS is an atomic instruction that performs two operations:
1. It reads the current value from a memory location.
2. It writes 1 to that same memory location.
0 indicates the lock is free.
1 indicates the lock is acquired (held by some thread).

Spinlocks
 A spinlock is a type of lock mechanism in which a thread repeatedly checks (or "spins") to see if the lock
is available before acquiring it. This busy-wait loop continues until the lock can be acquired.
 Spinlocks are particularly useful for short-duration critical sections, where waiting threads can quickly
acquire the lock without the overhead of context switching.
 However, if the lock is held for a long time, spinlocks can waste CPU cycles because threads keep spinning
without doing productive work.
 Spinlocks are lightweight and efficient compared to other synchronization methods, such as semaphores
or mutexes, because they avoid blocking and thread suspension overhead.

6. CPU scheduling in multicore systems: (JUST summary alone)

There are basic scheduling algorithms like FCFS (First-Come, First-Served), SJF (Shortest Job First), Priority,
and Round Robin. CPU scheduling in multicore systems presents unique challenges and opportunities
compared to single-processor scheduling.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Differences from Single-Core Scheduling:

 Multicore systems introduce cache hierarchies, memory coherence protocols, and Non-Uniform Memory
Access (NUMA) architectures that significantly impact scheduling decisions
 Multiple processes can truly execute simultaneously, enabling better system throughput and
responsiveness
Challenges in Multicore Scheduling
 Cache Affinity: A process builds state in a cache and Translation Lookaside Buffer (TLB); moving it
to another CPU forces cache reloads, degrading performance
 Cache Coherence: Hardware protocols (e.g., bus snooping) maintain coherence but add latency to
memory operations
 Balancing workload across cores often conflicts with maintaining cache affinity. Poor balancing leaves
cores idle; excessive migration destroys cache locality
 Scheduler data structures need synchronization, causing bottlenecks as the core count grows
 Algorithms effective for a few cores may degrade on many-core systems
Scheduling in Multiprocessor Systems:
 Processor Affinity: Attempting to keep a process running on the same processor to exploit cache locality.
 Load Balancing: Distributing processes evenly across multiple processors to maximize utilization.
 Gang Scheduling: Scheduling a set of related threads or processes to run simultaneously on different
processors.
 Priority Scheduling with Aging: Dynamically adjusting priorities to prevent starvation of low-priority
processes.
 Multilevel Queue Scheduling: Using multiple queues with different scheduling algorithms for different
process types like interactive and batch processes.
 Multilevel Feedback Queue Scheduling: Allowing processes to move between queues based on their CPU
burst characteristics.
 Fair-Share Scheduling: Ensuring that each user or group of users receives a fair share of CPU time.
 Single-Queue Multiprocessor Scheduling (SQMS): One global ready queue shared by all CPUs.
 Affinity mechanisms partially reduce cache penalties but add complexity
 Multi-Queue Multiprocessor Scheduling (MQMS): Each CPU has its own ready queue; processes assigned
on arrival.
 Work Stealing Algorithms: Local queues per CPU. Idle CPUs steal tasks from busy ones. Tasks stolen
from the back of the queue.
 Variants: Balanced Work Stealing (throttles wasteful thieves); Hierarchical Work Stealing for large
systems.
 NUMA-Aware Scheduling: In NUMA, CPUs access local memory faster than remote.
 Real-Time Scheduling: Critical in systems with strict timing constraints.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Rate-Monotonic Scheduling: Assigning priorities based on the inverse of the period of a periodic task.
 Earliest Deadline First (EDF): Assigning priorities based on the earliest deadline of a task.
 Variants: Global, Partitioned, Hybrid EDF.
References
1. Tanenbaum, A. S., & Bos, H. (2023). Modern Operating Systems. Pearson.
2. Silberschatz, A., Galvin, P. B., & Gagne, G. (2022). Operating System Concepts. Wiley.
3. Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. (2020). Operating Systems: Three Easy Pieces.
4. Anderson, T., & Dahlin, M. (2021). Operating Systems: Principles and Practice. Recursive Books.

Activity: CPU scheduler simulation for multicore systems.

A CPU scheduler simulation for multicore systems involves modeling how an operating system assigns and
manages processes or threads across multiple central processing unit (CPU) cores. It is used to evaluate the
efficiency of different scheduling algorithms in scenarios that include multiple simultaneous tasks.

Key components of a multicore scheduler simulation

 Processes and threads: These are the tasks that need to be executed by the CPU. For each, you must define
key parameters such as arrival time, burst time (the CPU time needed for execution), and priority (if using a
priority-based algorithm).

 Multicore processor: The simulation needs a defined number of CPU cores. The cores can be identical
(homogeneous) or have different capabilities and speeds (heterogeneous).

 Ready queue: This is a queue of processes or threads that are ready and waiting to be assigned to a CPU core.
In multicore systems, this can be a single shared queue or multiple private queues, one for each core.

 Scheduling algorithm: The core logic of the simulation. This determines which process from the ready queue
is assigned to which CPU core and when.

 Performance metrics: The simulation must measure key performance indicators to compare different
algorithms. Common metrics include:

 Throughput: The number of processes completed per unit of time.

 Average waiting time: The average time processes spend waiting in the ready queue.

 Average turnaround time: The average total time from a process's arrival to its completion.

 CPU utilization: The percentage of time the CPU cores are busy.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Load balancing: How evenly the workload is distributed across all cores.

Common multicore scheduling algorithms

The following are types of scheduling algorithms you can simulate for a multicore system:

 First-Come, First-Served (FCFS): A non-preemptive algorithm where processes are assigned to the first
available core in the order they arrive. For multicore, a single shared ready queue might feed processes to any
available core.

 Shortest Job First (SJF) and Shortest Remaining Time First (SRTF): These algorithms prioritize processes
based on the shortest burst time. In a multicore system, the next process with the shortest burst time is assigned
to any free core. SRTF is a preemptive version where a newly arriving process with a shorter remaining burst
time can preempt a running process.

 Round Robin (RR): A preemptive algorithm that allocates a small, fixed time quantum to each process. In a
multicore system, this is applied to processes across the available cores.

 Priority-based scheduling: This assigns processes to cores based on an internal or external priority value. The
highest-priority process is always chosen to run next. A preemptive version allows a high-priority process to
interrupt a lower-priority one.

 Multilevel Queue and Multilevel Feedback Queue: These use multiple ready queues, with different
scheduling algorithms and priorities for each queue. A multicore simulation would assign cores to these
different priority queues.

 Dynamic scheduling and load balancing: More advanced approaches that focus on keeping the workload
balanced across all cores, often by migrating tasks between cores if one becomes overloaded.

How to perform the simulation

To conduct the simulation, you can follow these steps:

1. Define your parameters: Specify the number of CPU cores, the scheduling algorithm to be tested, and a set of
processes with attributes like arrival time, burst time, and priority.

2. Model the system: Create a representation of your multicore system, including the ready queue(s) and the state
of each core (idle or busy).

3. Implement the algorithm: Write the code that dictates how the processes move from the ready queue to an
available CPU core based on the chosen algorithm.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

4. Run the simulation: Advance a global clock and update the state of each process and core in discrete time
steps. A process may run, wait, arrive, or complete during each step.

5. Calculate performance metrics: After the simulation concludes, use the data collected to calculate and display
the performance metrics, often using a Gantt chart to visualize the schedule.

6. Compare results: Repeat the process with different algorithms and compare the performance metrics to
evaluate which is most suitable for a given workload.

Tools for simulation

For hands-on practice, you can build a simulator from scratch using a programming language like Python, C++,
or Java. Several web-based visualizers are also available to help understand the concepts:

 MathWorks Simulink: A graphical environment that can model complex systems, including multicore
schedulers.

 GitHub projects: Many developers have created open-source CPU scheduling simulators in various
programming languages. These can be used as a starting point for your project.

 Online Visualizers: Numerous websites provide interactive visualizations of standard CPU scheduling
algorithms.

[Link] AP/CSE SUDHARSAN ENGINEERING COLLEGE

M.E - CSE , ADVANCED OPERATING SYSTEMS
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

UNIT II
Memory and Resource Management in Modern OS

Memory and Resource Management in Modern OS: Virtual memory, demand paging,
page replacement policies-Huge pages, NUMA-aware memory management-Resource
allocation in cloud-native environments.

Activity: Simulate demand paging and page replacement algorithms.

INTRODUCTION

VIRTUAL MEMORY
Virtual memory is a memory management technique used by operating systems to give
the appearance of a large, continuous block of memory to applications, even if the
physical memory (RAM) is limited and not necessarily allocated in contiguous manner.
The main idea is to divide the process in pages, use disk space to move out the pages if
space in main memory is required and bring back the pages when needed.

How Virtual Memory Works

 Virtual memory uses both hardware and software to manage memory.

 When a program runs, it uses virtual addresses (not real memory locations).
 The computer system converts these virtual addresses into physical addresses (actual
locations in RAM) while the program runs.
Types of Virtual Memory
In a computer, virtual memory is managed by the Memory Management Unit (MMU),
which is often built into the CPU. The CPU generates virtual addresses that the MMU
translates into physical addresses. There are two main types of virtual memory:
1. Paging

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

2. Segmentation

1. Paging

Paging divides memory into small fixed-size blocks called pages. When the computer
runs out of RAM, pages that aren't currently in use are moved to the hard drive, into an
area called a swap file. Here,
 The swap file acts as an extension of RAM.
 When a page is needed again, it is swapped back into RAM, a process known as page
swapping.
 This ensures that the operating system (OS) and applications have enough memory to
run.
Page Fault Service Time: The time taken to service the page fault is called page fault
service time. The page fault service time includes the time taken to perform all the above
six steps.
 Let Main memory access time is: mm
 Page fault service time is: ss
 Page fault rate is : pp
 Then,Effective memory access time = (p∗ s)+(1−p)∗ m(p∗ s)+(1−p)∗ m
Page and Frame: Page is a fixed size block of data in virtual memory and a frame is a
fixed size block of physical memory in RAM where these pages are loaded.
 Think of a page as a piece of a puzzle (virtual memory) While, a frame as the spot
where it fits on the board (physical memory).
 When a program runs its pages are mapped to available frames so the program can
run even if the program size is larger than physical memory.

2. Segmentation

Segmentation divides virtual memory into segments of different sizes. Segments that
aren't currently needed can be moved to the hard drive. Here,
 The system uses a segment table to keep track of each segment's status, including
whether it's in memory, if it's been modified and its physical address.
 Segments are mapped into a process's address space only when needed.
Read more about - Segmentation

Applications of Virtual memory

Virtual memory has the following important characteristics that increase the capabilities
of the computer system.
 Increased Effective Memory: It enables a computer to have more memory than the
physical memory using the disk space. This allows for the running of larger
applications.
 Memory Isolation: Virtual memory allocates a unique address space to each process,
such separation increases safety and reliability based on the fact that one process
cannot interact with another.
 Efficient Memory Management: Virtual memory also helps in better utilization of
the physical memories through methods that include paging and segmentation.
 Simplified Program Development: For case of programmers, they can program ‘as
if’ there is one big block of memory and this makes the programming easier and more
efficient in delivering more complex applications.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Management of Virtual Memory

Here are 5 key points on how to manage virtual memory:

1. Adjust the Page File Size

 Automatic Management: All contemporary OS including Windows contain the

auto-configuration option for the size of the empirical page file. But depending on the
size of the RAM, they are set automatically, although the user can manually adjust
the page file size if required.
 Manual Configuration: For tuned up users, the setting of the custom size can
sometimes boost up the performance of the system. The initial size is usually advised
to be set to the minimum value of 1.

2. Place the Page File on a Fast Drive

 SSD Placement: If this is feasible, the page file should be stored in the SSD instead
of the HDD as a storage device. It has better read and write times and the virtual
memory may prove beneficial in an SSD.
 Separate Drive: Regarding systems having multiple drives involved, the page file
needs to be placed on a different drive than the OS and that shall in turn improve its
performance.

3. Monitor and Optimize Usage

 Performance Monitoring: Employ the software tools used in monitoring the

performance of the system in tracking the amounts of virtual memory.
 Regular Maintenance: Make sure there is no toolbar or other application running in
the background, take time and uninstall all the tool bars to free virtual memory.

4. Disable Virtual Memory for SSD

 Sufficient RAM: If for instance your system has a big physical memory,
 Example: 16GB and above then it would be advised to freeze the page file in order to
minimize SSD usage. But it should be done, carefully and only if the additional
signals that one decides to feed into his applications should not likely use all the
available RAM.

5. Optimize System Settings

 System Configuration: Change some general properties of the system concerning

virtual memory efficiency. This also involves enabling additional control options in
Windows.
 Regular Updates: Ensure that your drivers are run in their newest version because
new releases contain some enhancements and issues regarding memory management.

Benefits of Using Virtual Memory

 Supports Multiprogramming & Larger Programs : Virtual memory

allows multiple processes to reside in memory at once by using demand paging. Even
programs larger than physical memory can be executed efficiently.
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Maximizes Application Capacity : With virtual memory, systems can run more
applications simultaneously, including multiple large ones. It also allows only
portions of programs to be loaded at a time, improving speed and reducing memory
overhead.
 Eliminates Physical Memory Limitations : There's no immediate need to upgrade
RAM as virtual memory compensates using disk space.
 Boosts Security & Isolation : By isolating the memory space for each process,
virtual memory enhances system security. This prevents interference between
applications and reduces the risk of data corruption or unauthorized access.
 Improves CPU & System Performance: Virtual memory helps the CPU
by managing logical partitions and memory usage more effectively. It allows for cost-
effective, flexible resource allocation, keeping CPU workloads optimized and
ensuring smoother multitasking.
 Enhances Memory Management Efficiency : Virtual memory automates memory
allocation, including moving data between RAM and disk without user intervention.
It also avoids external fragmentation, using more of the available memory effectively
and simplifying OS-level memory management.

Limitation of Virtual Memory

 Slower Performance: Virtual memory can slow down the system, because it often
needs to move data between RAM and the hard drive.
 Risk of Data Loss: There is a higher risk of losing data if something goes wrong,
like a power failure or hard disk crash, while the system is moving data between
RAM and the disk.
 More Complex System: Managing virtual memory makes the operating system more
complex. It has to keep track of both real memory (RAM) and virtual memory and
make sure everything is in the right place.

Page replacement policies-Huge pages:

Page Replacement Policies

The goal of a page replacement policy is to minimize the number of page faults.

(a) FIFO (First-In, First-Out) Policy

The oldest loaded page in memory is replaced [Link], but may lead to Belady’s
anomaly (more frames → more faults).

Example:
If pages are loaded in order A, B, C, D and a new page E must be loaded, then A (the
oldest) is replaced.

(b) LRU (Least Recently Used) Policy

Replaces the page that has not been used for the longest time.
Based on the idea of temporal locality.
More accurate but costly to implement (needs timestamp or counter).

(c) Optimal Page Replacement Policy

Replaces the page that will not be used for the longest time in the future.
Gives minimum number of page faults, but not practical (future references are
unknown).
Used for theoretical comparison.
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

(d) LFU (Least Frequently Used) Policy

Replaces the page that has been used least number of times.
Requires counting page accesses.
Works well when pages are accessed with stable frequency.

(e) MFU (Most Frequently Used) Policy

Replaces the page that has been used the most frequently (assuming it’s less likely
to be used again soon).

3. Huge Pages
Definition
A Huge Page (or Large Page) is a memory page much larger than the standard
page size.
Example:
Normal page size: 4 KB
Huge page size: 2 MB or 1 GB (depending on system)
Purpose:
To reduce overhead of managing too many small pages.
To increase performance of applications that use large contiguous memory (e.g.,
databases, virtual machines).

NUMA-aware memory management-Resource allocation in cloud-native

environments:

1. Introduction

In modern high-performance and cloud-native platforms, efficient resource allocation plays

a critical role in providing low-latency and scalable services. Two key concepts in this
domain are NUMA-aware memory management and optimized resource allocation
mechanisms used in containerized cloud infrastructures such as Kubernetes.

2. NUMA Architecture Overview

NUMA (Non-Uniform Memory Access) is a memory design used in multi-processor

servers where:

Each CPU socket has local memory, and accessing it is [Link] memory
belonging to another CPU socket (remote memory) incurs higher latency.

Comparison:

Feature UMA NUMA

Memory access time Uniform for all CPUs Varies (local faster than remote)
Scalability Limited Highly scalable
Suitable for Small systems Multi-socket servers & cloud workloads

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

3. NUMA-Aware Memory Management

NUMA-aware memory management ensures that:

 Threads are scheduled on the same CPU node where their memory is allocated.
 Memory pages are allocated close to the running CPU core to reduce latency.

Techniques Used

 Memory locality optimization

Allocating memory in the same NUMA node as the executing thread.
 Thread and process pinning (CPU affinity)
Binding processes or containers to specific CPU nodes.
 NUMA balancing
The OS monitors memory access patterns and migrates pages automatically if
needed.
 NUMA-aware container orchestration
Kubernetes, Docker, and hypervisors allocate CPU/memory respecting NUMA
boundaries.

Benefits

 Reduced latency & faster execution

 Lower inter-socket communication overhead
 Higher throughput & performance consistency

4. Cloud-Native Resource Allocation

Cloud-native environments use container orchestration platforms like Kubernetes,

Docker Swarm, and OpenShift to efficiently allocate compute, memory, network, and
storage resources.

Key Characteristics

 Microservices-based deployment
 Dynamic scaling (auto-scaling, horizontal & vertical)
 Resource isolation via cgroups and namespaces
 Policy-driven scheduling

5. Resource Allocation Strategy in Kubernetes

I. Resource Requests and Limits

 Requests: Minimum guaranteed CPU/memory

 Limits: Maximum allowed value to avoid starvation or overuse

II. QoS (Quality of Service) Classes

 Guaranteed
 Burstable
 Best-effort

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

III. Node Affinity & Taints/Tolerations

Ensures workloads are scheduled to appropriate hardware.
IV. NUMA-aware Scheduling (Topology Manager)
Aligns CPU, huge pages, and device memory to same NUMA region to improve
performance.

6. NUMA + Cloud-Native Integration

Challenge Solution
Multi-node memory latency NUMA binding and CPU pinning
Container mobility NUMA topology aware scheduler
Real-time/AI workloads HugePages, SR-IOV, DPDK
Resource fragmentation Static + dynamic pooling

7. Use-Case Examples

 High-performance computing (HPC)

 AI/ML and deep learning workloads
 Real-time streaming and telecom (5G core)
 High-frequency trading (HFT) systems
 In-memory databases (Redis, Cassandra)

NUMA-Aware Memory Management & Resource Allocation in Cloud-Native

Environments

1. Introduction

Modern cloud platforms deploy applications across large-scale multi-core servers. These
servers often use Non-Uniform Memory Access (NUMA) architecture to improve
performance. Effective NUMA-aware memory management is essential to minimize
latency, improve throughput, and optimize resource utilization for cloud-native workloads
such as microservices and containerized applications (Docker, Kubernetes).

2. What is NUMA?

NUMA is a hardware memory architecture where:

 A system contains multiple CPU sockets.

 Each socket has local memory, forming a NUMA node.
 A CPU can access its local memory faster than memory attached to another NUMA
node.

Local access → Low latency & high bandwidth

Remote access → High latency & reduced performance

3. NUMA-Aware Memory Management

NUMA-aware management ensures that threads/processes are scheduled on CPUs close

to their allocated memory.

Key principles:

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Locality preservation: Place memory near compute tasks.

Avoid remote memory access: Reduce cross-node communication.

Intelligent scheduling: CPU cores and memory should be allocated from the same NUMA
node.

Memory binding policies: OS decides how pages are allocated

First-touch, Interleaving, Preferred-node policies.

4. Tools & Support Technologies

Layer Examples
OS-level Linux cgroups, taskset, numactl
Virtualization KVM, VMware NUMA scheduler
Containers Kubernetes Topology Manager, CPU Manager
Cloud Platforms AWS Nitro, Azure HBv3, GCP Compute Optimized

5. Resource Allocation in Cloud-Native Environments

Cloud-native systems rely on containers, microservices, orchestration, and auto-scaling,

where workloads move dynamically. NUMA-aware allocation becomes challenging but
essential.

Key Strategies & Components

Topology-aware scheduling (Kubernetes):

Ensures pods are placed on nodes respecting CPU/memory topology.

Cgroup-based resource isolation:

Controls CPU and memory usage per container.

Memory affinity policies:

Memory is pinned to the NUMA node closest to the assigned CPU.

Hardware-aware orchestration:
Kubernetes enables Topology Manager + CPU Manager + HugePages for high-
performance applications (AI/graph analytics).

6. Benefits

Benefits Description
Reduced Latency Local memory access increases speed
Higher Throughput Improved data processing for workloads
Better Scalability Efficient sharing of NUMA nodes
Predictable QoS Improved SLO for cloud-native apps

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

7. Challenges

 Containers may migrate across nodes, breaking memory locality.

 Multi-threaded applications need careful binding.
 Over-subscription can lead to noisy-neighbor effects.
 Requires NUMA-aware scheduling support from OS, VM, and orchestration layers.

8. Real-World Use Cases

AI/ML model training

Big data analytics (Spark, Hadoop, Kafka)

Telecommunications (5G NFV)

High-performance computing (HPC)

9. Conclusion

NUMA-aware memory management is critical in modern multi-core, cloud-native, and

container-based environments. Integrating NUMA-topology awareness at the OS,
virtualization, and orchestration layers significantly improves performance, scalability, and
resource efficiency.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT - III
Virtualization and Containerization: Hypervisors (Type I & II), KVM, QEMU,
XenContainers: Docker, LXC, systemd-nspawn-OS-level virtualization and namespaces

Hypervisors (Type I & II)

 A cloud hypervisor is the software, firmware, or a virtual machine monitor (VMM)
that creates and manages virtual machines (VMs) on a physical host. It is the core
component of virtualization that allocates and multiplexes the physical hardware
resources (like CPU, memory, and storage) among the various VMs, enabling them
to run concurrently.

Functions of a Hypervisor

1. Virtual Machine Creation:

The hypervisor creates and configures multiple VMs on a single physical host.
2. Resource Allocation:
It allocates CPU time, memory, and storage space to each VM as required.
3. Isolation:
Each VM is isolated from others, ensuring that a crash or virus in one VM doesn’t
affect others.
4. Monitoring and Management:
The hypervisor monitors the performance and status of VMs and manages their
lifecycle (start, stop, suspend, migrate).
5. Hardware Virtualization:
It translates VM instructions into hardware-level commands so VMs can use the
physical hardware efficiently.

Architecture of a Hypervisor

The hypervisor sits between the hardware layer and the virtual machines (guest OSes).
It controls how hardware resources are distributed and accessed by each VM.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Types of Hypervisors

Hypervisors are mainly classified into two types:

Type 1 – Bare Metal Hypervisor

 A Type 1 hypervisor runs directly on the physical hardware of the host machine.
 It does not require an underlying operating system.
 Because it communicates directly with the hardware, it provides high performance,
better security, and reliability.

Examples:

 VMware ESXi
 Microsoft Hyper-V (Server version)
 Citrix XenServer
 KVM (Kernel-based Virtual Machine)

Advantages:

 High performance due to direct hardware access

 Strong isolation between VMs
 Better scalability and efficiency
 Commonly used in enterprise and cloud data centers

Disadvantages:

 Complex installation and management

Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Requires specialized hardware and technical expertise

Use Cases:

 Data centers
 Cloud computing platforms (AWS, Azure)
 Server virtualization

2. Type 2 – Hosted Hypervisor

 A Type 2 hypervisor runs on top of an existing operating system (the host OS).
 The hypervisor relies on the host OS to communicate with hardware.
 It is easier to install and manage but slightly slower compared to Type 1 because of
the additional OS layer.

Examples:

 Oracle VirtualBox
 VMware Workstation
 Parallels Desktop (for macOS)

Advantages:

 Easy to install and use

 Ideal for testing, learning, and software development
 No need for dedicated hardware

Disadvantages:

 Slightly lower performance due to OS overhead

 Less secure than Type 1 hypervisors
 Not suitable for large-scale production environments

Use Cases:

 Personal computers
 Software testing and development environments
 Academic and training purposes

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

KVM

What is KVM?

Kernel-based Virtual Machine (KVM) is a software feature that you can install on
physical Linux machines to create virtual machines. A virtual machine is a software
application that acts as an independent computer within another physical computer. It
shares resources like CPU cycles, network bandwidth, and memory with the physical
machine. KVM is a Linux operating system component that provides native support for
virtual machines on Linux. It has been available in Linux distributions since 2007.

Why is KVM important?

Kernel-based Virtual Machine (KVM) can turn any Linux machine into a bare-
metal hypervisor. This allows developers to scale computing infrastructure for different
operating systems without investing in new hardware. KVM frees server administrators
from manually provisioning virtualization infrastructure and allows large numbers of
virtual machines to be deployed easily in cloud environments.

Businesses use KVM because of the following advantages.

High performance

KVM is engineered to manage high-demanding applications seamlessly. All guest

operating systems inherit the high performance of the host operating system—Linux. The
KVM hypervisor also allows virtualization to be performed as close as possible to the
server hardware, which further reduces process latency.

Security

Virtual machines running on KVM enjoy security features native to the Linux
operating system, including Security-Enhanced Linux (SELinux). This ensures that all
virtual environments strictly adhere to their respective security boundaries to strengthen
data privacy and governance.

Stability

KVM has been widely used in business applications for more than a decade. It
enjoys excellent support from a thriving open-source community. The source code that
powers KVM is mature and provides a stable foundation for enterprise applications.

Cost efficiency

KVM is free and open source, which means businesses do not have to pay
additional licensing fees to host virtual machines.

Flexibility
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

KVM provides businesses many options during installations, as it works with

various hardware setups. Server administrators can efficiently allocate additional CPU,
storage, or memory to a virtual machine with KVM. KVM also supports thin provisioning,
which only provides the resources to the virtual machine when needed.

How does KVM work?

Kernel-based Virtual Machine (KVM) requires a Linux kernel installation on a

computer powered by a CPU that supports virtualization extensions. Specifically, KVM
supports all x86 CPUs, a family of computer chips capable of processing the Intel x86
instruction language.

Linux kernel

Linux kernel is the core of the open-source operating system. A kernel is a low-
level program that interacts with computer hardware. It also ensures that software
applications running on the operating system receive the required computing resources.
Linux distributions, such as Red Hat Enterprise Linux, Fedora, and Ubuntu, pack the Linux
kernel and additional programs into a user-friendly commercial operating system.

How to enable KVM

Once you have installed the Linux kernel, you need to install the following
additional software components on the Linux machine:

 A host kernel module

 A processor-specific module
 An emulator
 A range of other Linux packages for expanding KVM’s capabilities and performance

Once loaded, the server administrator creates a virtual machine via the command
line tool or graphical user interface. KVM then launches the virtual machine as an
individual Linux process. The hypervisor allocates every virtual machine with virtual
memory, storage, network, CPU, and resources.

What is the difference between KVM and VMware?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

VMware is the software company that produces VMware ESXi, a commercially

licensed virtualization solution. VMware hypervisors are used for enterprise applications,
with virtual machines capable of handling heavy workloads.

Kernel-based Virtual Machine (KVM) and VMware ESXi both provide

virtualization infrastructure to deploy type 1 hypervisors on the Linux kernel. However,
KVM is an open-source feature while VMware ESXi is available via commercial licenses.

Organizations using VMware’s virtualization components enjoy professional

support from its technical team. Meanwhile, KVM users rely on a vast open-source
community to address potential issues.

How does AWS help with KVM?

Amazon Linux 2 is an Amazon Web Services (AWS) Linux distribution that runs
cloud applications in a stable, secure, and high-performance environment. Amazon Linux 2
is available as virtual machine images for development and testing on these virtualization
platforms: Kernel-based Virtual Machine (KVM), Microsoft Hyper-V, Oracle VM
VirtualBox, and VMware ESXi.

Here are other benefits of Amazon Linux 2:

 Amazon Linux 2 comes with packages and configurations for easy integration with other
AWS services
 Developers can use Amazon Linux 2 for on-premises testing to support local development
 Amazon Linux 2 automatically applies security patches without rebooting
 Organizations using Amazon Linux 2 enjoy long-term support for security updates and
five years of support for bug fixes
QEMU
The Quick Emulator (QEMU) is a free and open-source emulator that uses
dynamic binary translation to emulate a computer's processor; that is, it translates the
emulated binary codes to an equivalent binary format which is executed by the machine. It
provides a variety of hardware and device models for the virtual machine, enabling it to run
different guest operating systems. QEMU supports the emulation
of x86, ARM, PowerPC, RISC-V, and other architectures.

Licensing
QEMU is free software developed by Fabrice Bellard. Different components of
QEMU are licensed under the GNU General Public License (GPL), BSD license, GNU
Lesser General Public License (LGPL), or other GPL-compatible licenses.

Operating modes
QEMU has multiple operating modes:

 User-mode emulation. In the user emulation mode, QEMU runs

single Linux or Darwin/macOS programs that were compiled for a different instruction
set. System calls are thunked for endianness and for 32/64-bit mismatches. Fast cross-
compilation and cross-debugging are the main targets for user-mode emulation.
 System emulation. In the system emulation mode, QEMU emulates a full computer
system, including peripherals. It can be used to provide virtual hosting of several virtual
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

computers on a single computer. QEMU can boot many guest operating systems,
including Linux, Solaris, Microsoft Windows, DOS, and BSD;it supports emulating
several instruction sets, including x86, x86-
64, MIPS, ARMv7, ARMv8, PowerPC, RISC-V, SPARC, ETRAX
CRIS and MicroBlaze.
 Hypervisor support. In the hypervisor support mode, QEMU either acts as a Virtual
Machine Manager (VMM) or as a device emulation back-end for virtual
machines running under a hypervisor. The most common is Linux's KVM but the
project supports a number of hypervisors including Xen, Apple's HVF, Windows'
WHPX, and NetBSD's NVMM.
Features
QEMU supports the emulation of various architectures, including x86, MIPS64 (up
to Release 6),[9] SPARC (sun4m and sun4u), ARM (Integrator/CP and
Versatile/PB), SuperH, PowerPC (PReP and Power Macintosh), ETRAX
CRIS, MicroBlaze, and RISC-V. It supports saving the virtual machine state while all
programs are running. Guest operating systems do not need patching to run inside QEMU.

The virtual machine can interface with many types of physical host hardware,
including the user's hard disks, CD-ROM drives, network cards, audio interfaces, and USB
devices. USB devices can be emulated entirely, or the host's USB devices can be used,
although this requires administrator privileges and does not work with some devices.

Virtual disk images can be stored in QCOW format, which can significantly reduce
image size.

The QCOW2 format also allows the creation of overlay images, which are files that
store only the changes made from an original (unmodified) base image file. This enables
the emulated disk's contents to be reverted to an earlier state. For instance, a base image
could contain a fresh installation of a known working operating system, and overlay
images can be used to record changes. Should the guest system become unusable (through
virus attack, accidental system destruction, etc.), the user can delete the overlay and use an
earlier emulated disk image.

QEMU can emulate network cards (of different models) that share the host system's
connectivity by translating network addresses, effectively allowing the guest to use the
same network as the host. QEMU integrates several services to allow the host and guest
systems to communicate for example: an integrated SMB server and network-port
redirection (to allow incoming connections to the virtual machine). It can also boot Linux
kernels without a bootloader.

QEMU does not depend on the presence of graphical output methods on the host
system. Instead, it provides access to the guest OS screen via an integrated VNC server. It
can also use an emulated serial line without any screen, with applicable operating systems.

Simulating multiple CPUs running SMP is possible.

QEMU does not require administrative rights to run unless additional kernel
modules are used to improve speed (like KQEMU) or certain modes of its network
connectivity model are utilized.

Tiny Code Generator

The Tiny Code Generator (TCG) aims to remove the shortcoming of relying on a
particular version of GCC or any compiler, instead incorporating the compiler into other
tasks performed by QEMU at run time. Optional optimization passes are performed
between them, for a just-in-time compiler (JIT) mode.
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

TCG requires dedicated code written to support every architecture it runs on, so that
the JIT knows what to translate the TCG ops to. If no dedicated JIT code is available for
the architecture, TCG falls back to a slow interpreter mode called TCG Interpreter (TCI). It
also requires updating the target code to use TCG ops instead of the old DynGen ops.

Starting with QEMU Version 0.10.0, TCG ships with the QEMU stable release. It
replaces DynGen, which relied on GCC 3.x to work.

Accelerator
KQEMU was a Linux kernel module, also written by Fabrice Bellard, which
notably sped up emulation of x86 or x86-64 guests on platforms with the same CPU
architecture. This worked by running user mode code (and optionally some kernel code)
directly on the host computer's CPU, and by using processor and peripheral emulation only
for kernel-mode and real-mode code.

QVM86 was a GNU GPLv2 licensed drop-in replacement for the then closed-source
KQEMU. The developers of QVM86 ceased development in January 2007.

Kernel-based Virtual Machine (KVM) has mostly taken over as the Linux-based hardware-
assisted virtualization solution for use with QEMU following the lack of support for
KQEMU and QVM86.

Intel's Hardware Accelerated Execution Manager (HAXM) is an open-source alternativeto

KVM for x86-based hardware-assisted virtualization on NetBSD, Linux, Windows and
macOS using Intel VT. QEMU also supports the following accelerators:

 hvf, Apple's [Link] based on Intel VT.

 whpx, Microsoft's Windows Hypervisor Platform based on Intel VT or AMD-V.
 tcg, QEMU's own Tiny Code Generator. This is the default.
Supported disk image formats
QEMU supports the following disk image formats:

 macOS Universal Disk Image Format (.dmg) – Read-only

 Bochs – Read-only
 Linux cloop – Read-only
 Parallels disk image (.hdd, .hds) – Read-only
 QEMU copy-on-write (.qcow2, .qed, .qcow, .cow)
 VirtualBox Virtual Disk Image (.vdi)
 Virtual PC Virtual Hard Disk (.vhd)
 Virtual VFAT
 VMware Virtual Machine Disk (.vmdk)
 Raw images (.img) that contain sector-by-sector contents of a disk
 CD/DVD images (.iso) that contain sector-by-sector contents of an optical disk (e.g.
booting live OSes)
QEMU Object Model
The QEMU Object Model (QOM) provides a framework for registering types that
users can make and instantiating objects from those types.

QOM provides the following features:

 System for dynamically registering types

 Support for single-inheritance of types
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Multiple inheritances of stateless interfaces

See also: Object model
Parallel emulation
Virtualization solutions that use QEMU can execute multiple virtual CPUs in
parallel. For user-mode emulation, QEMU maps emulated threads to host threads. QEMU
can run a host thread for each emulated virtual CPU (vCPU) for full system emulation.
This depends on the guest being updated to support parallel system emulation, currently
ARM, Alpha, HP-PA, PowerPC, RISC-V, s390x, x86, and Xtensa. Otherwise, a single
thread is used to emulate all virtual CPUs (vCPUs), which executes each vCPU in a round-
robin manner.

Integration
VirtualBox
VirtualBox, first released in January 2007, used some of QEMU's virtual hardware
devices, and had a built-in dynamic re-compiler based on QEMU. As with KQEMU,
VirtualBox runs nearly all guest code natively on the host via the VMM (Virtual Machine
Manager) and uses the re-compiler only as a fallback mechanism – for example, when
guest code executes in real mode.

Xen-HVM
Xen, a virtual machine monitor, can run in HVM (hardware virtual machine) mode,
using Intel VT-x or AMD-V hardware x86 virtualization extensions and ARM Cortex-
A7 and Cortex-A15 virtualization [Link] means that instead of para-virtualized
devices, a real set of virtual hardware is exposed to the DomU, enabling it to use real
device drivers.

QEMU includes several components: CPU emulators, emulated devices, generic

devices, machine descriptions, user interface, and a debugger. The emulated devices and
generic devices in QEMU make up its device models for I/O [Link] comprise
a PIIX3 IDE (with some rudimentary PIIX4 capabilities), Cirrus Logic or plain VGA
emulated video, RTL8139 or E1000 network emulation, and ACPI [Link] support is
provided by Xen.

Xen-HVM utilizes device emulation based on the QEMU project to deliver I/O
virtualization to virtual machines (VMs). Hardware is emulated through a QEMU "device
model" daemon running as a backend in Dom0. Unlike other QEMU modes, such as
dynamic translation or KVM, the hypervisor fully manages virtual CPUs, pausing them as
necessary while QEMU handles memory-mapped I/O emulation.

KVM
KVM (Kernel-based Virtual Machine) is a FreeBSD and Linux kernel module that
allows a user space program access to the hardware virtualization features of various
processors, with which QEMU can offer virtualization for x86, PowerPC, and S/390 guests.
When the target architecture is the same as the host architecture, QEMU can make use of
KVM particular features, such as acceleration.

Win4Lin Pro Desktop

In early 2005, Win4Lin introduced Win4Lin Pro Desktop, based on a 'tuned'
version of QEMU and KQEMU and it hosts NT-versions of Windows. In June
2006,Win4Lin released Win4Lin Virtual Desktop Server based on the same code base.
Win4Lin Virtual Desktop Server serves Microsoft Windows sessions to thin clients from a
Linux server.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

In September 2006, Win4Lin announced a change of the company name to Virtual

Bridges with the release of Win4BSD Pro Desktop, a port of the product to FreeBSD and
PC-BSD. Solaris support followed in May 2007 with the release of Win4Solaris Pro
Desktop and Win4Solaris Virtual Desktop Server.

SerialICE
SerialICE is a QEMU-based firmware debugging tool running system firmware
inside of QEMU while accessing real hardware through a serial connection to a host
system. This can be used as a cheap replacement for hardware in-circuit emulators (ICE).

WinUAE
WinUAE introduced support for the CyberStorm PPC and Blizzard 603e
boards using the QEMU PPC core in version 3.0.0.

Unicorn
Unicorn is a CPU emulation framework based on QEMU's "TCG" CPU emulator.
Unlike QEMU, Unicorn focuses on the CPU only: no emulation of any peripherals is
provided and raw binary code (outside of the context of an executable file or a system
image) can be run directly. Unicorn is thread-safe and has multiple bindings and
instrumentation interfaces.

Limbo x86 PC Emulator

Limbo is an x86 and ARM64 QEMU-based virtual machine for Android. It is one
of the few pieces of virtual machine software available for Android capable of emulating
Microsoft Windows, although it was designed to emulate Linux and DOS. Unlike other
QEMU-based emulators, it does not require users to type commands to use, instead having
a user interface to set the virtual machine's settings.

It is more popular in developing countries in Asia such as India, Malaysia, and Thailand on
YouTube due to the high usage of the Android Operating [Link] was removed
from the Google Play Store for unknown reasons between February 2019 and December
2020, though it can still be installed off the developer's website with an APK (Android
Package) installation. Limbo tends to have issues regarding its audio quality and playback.
No fixes have been found for these problems as of [Link], Limbo is less well-known
than other virtual machine software, which leads to less available information regarding its
troubleshooting.

Xen
Containers: Docker, LXC, systemd-nspawn-OS-level virtualization and namespaces

1. Xen Hypervisor

Definition

Xen is an open-source Type-1 (bare-metal) hypervisor that allows multiple operating

systems (VMs) to run concurrently on the same hardware. It uses paravirtualization and
hardware-assisted full virtualization.

Architecture

Xen architecture includes two main domains:

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Component Description
Privileged control domain running Linux, manages hardware and VM
Dom0
lifecycle
DomU Unprivileged guest VMs that run user workloads

Virtualization Modes

Mode Description
Guest OS modified; faster I/O, no hardware assist
Paravirtualization (PV)
required
Hardware Virtualization
Guest OS unmodified; uses Intel VT-x/AMD-V
(HVM)
PVH Hybrid of PV + HVM for efficiency

Key Features

 Live migration
 Resource isolation and security through microkernel architecture
 Used in AWS EC2 (older generations), Citrix Hypervisor

2. Containers / OS-Level Virtualization

Definition

Containers provide lightweight, OS-level virtualization where multiple isolated user-

space environments run on the same host kernel. Unlike hypervisors, containers do not
virtualize hardware.

Benefits

 Fast start-up time

 Minimal resource overhead
 Portable and scalable
 Ideal for microservices and DevOps

3. Container Technologies

a) Docker

Most popular container platform

Uses container images (layers) and Docker Engine

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Works with cgroups + namespaces for isolation

Supports image versioning, registries (Docker Hub), and orchestration (Kubernetes

Primary use cases: microservices, CI/CD, cloud-native applications

b) LXC (Linux Cntainers)

Low-level container management system

Provides containers similar to lightweight VMs

Uses the host Linux kernel and exposes a near-complete OS environment

Difference from Docker:

LXC = system containers
Docker = application containers

c) systemd-nspawn

Lightweight containerization tool built into systemd

Can boot full OS trees inside a container

Simpler than Docker; mostly used for debugging, testing, and system-level
sandboxing

4. OS-Level Virtualization and Namespaces

Linux provides kernel-level isolation mechanisms:

a) Namespaces

Namespaces isolate global system resources.

Types:

Namespace Purpose
PID Process isolation
NET Network interfaces & routing
IPC Shared memory & semaphores

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Namespace Purpose
MNT Filesystem mounts
UTS Hostname/domainname isolation
USER User ID & privilege isolation
CGROUP Resource accounting & limits

b) cgroups (Control Groups)

Used to limit, prioritize, and account CPU, memory, I/O, and network resources for
containers.

Comparison: Xen vs Containers

Containers (Docker/LXC/systemd-
Feature Xen Hypervisor
nspawn)
Level Hardware virtualization OS-level virtualization
Kernel Separate kernel per VM Shared host kernel
Overhead Higher Very low
Boot
Slow (seconds) Fast (milliseconds)
Speed
Isolation Very strong Strong, but shares kernel
Legacy apps, OS testing, cloud
Use Case Microservices, DevOps, CI/CD
VMs

Conclusion

Xen provides secure and strong hardware virtualization suitable for cloud
infrastructure and multi-OS environments.

Containers (Docker, LXC, systemd-nspawn) offer lightweight OS-level

virtualization for fast, scalable, DevOps-based application deployment.

Linux namespaces + cgroups are the core technologies powering container

isolation and resource control.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT - IV

Distributed Operating Systems and File Systems: Distributed scheduling,

communication, and synchronization-Distributed file systems: NFS, GFS,
HDFSTransparency issues and fault tolerance

Distributed Scheduling

Distributed communication

Distributed synchronization

Distributed file systems (NFS, GFS, HDFS) — each with architecture + stepwise
operation

Transparency issues

Fault tolerance (failure models, detection, recovery, replication, consensus)

1. Distributed scheduling

Definition / goal: decide where to run processes/tasks across multiple machines to meet
objectives (throughput, load-balance, latency, resource utilization).

Key ideas: centralized vs decentralized schedulers, load metrics, migration, proactive vs

reactive scheduling.

Step-by-step explanation

Collect resource information

 Each node reports CPU, memory, I/O, queue length, and possibly network cost.
 Measurements can be periodic or event-driven.

Make scheduling decision

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

 Centralized: one scheduler receives all info and assigns tasks.

 Decentralized: nodes negotiate or use distributed policies (e.g., work stealing,
distributed hash).
 Choice depends on scale and failure tolerance.

Match task to node

 Evaluate candidate nodes using policy (least loaded, earliest finish time, affinity, data
locality).
 For data-intensive tasks prefer nodes with data (to reduce network I/O).

Dispatch / start task

 Transfer program/data if necessary.

 Create process/container on chosen machine and start execution.

Monitor and adapt

 Track task progress and node load.

 If node becomes overloaded or fails, trigger migration or re-schedule remaining work.

Migration (if used)

 Checkpoint process/state.
 Transfer checkpoint to target node.
 Resume and update metadata (where task now runs).

Common algorithms / policies

Round-robin, least-loaded, earliest-finish, greedy, backfill (for batch jobs), work-

stealing (for parallel tasks).

Pros/Cons

Centralized: simple but single point of failure.

Decentralized: scalable and resilient but complexity and possible suboptimality.

2. Distributed communication

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Definition / goal: enable processes on different machines to exchange messages or share

data reliably and efficiently.

Communication models

 Message passing (explicit send/receive): e.g., sockets, RPC.

 Shared memory (distributed): implemented via distributed shared memory (DSM)
systems.
 Remote Procedure Call (RPC)/gRPC: abstraction of calling a remote function.
 Publish/Subscribe / Message brokers: decouples producers & consumers.

Step-by-step explanation (RPC example)

 Client stub marshals arguments into a message.

 Transport sends message over network (TCP/UDP).
 Server receives message, server stub unmarshals arguments.
 Server executes procedure and marshals result.
 Reply sent back; client receives and unmarshals result.

Key issues & techniques

Marshalling/unmarshalling: convert data structures to bytes and back.

Naming & location: how to locate remote services (DNS, registry).

Timeouts & retries: handle lost messages or crashes.

Ordering & reliability: use TCP for reliable ordered delivery or design protocols
otherwise.

Performance: batching, compression, reducing round trips.

Security: authentication, encryption (TLS), access controls.

3. Distributed synchronization

Definition / goal: coordinate concurrent actions on distributed processes so shared

resources are accessed correctly (mutual exclusion, ordering, consistency).

Common problems
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Mutual exclusion (only one process in critical section)

 Consensus (agree on a value)
 Leader election
 Global state snapshot / clock synchronization

Step-by-step explanation (Mutual exclusion — token ring & Ricart-Agrawala)

A. Token Ring

 Arrange nodes in logical ring.

 A single token circulates; only holder may enter critical section.
 After leaving, node passes token to next node.
 Guarantees mutual exclusion and fairness; but high latency if many nodes.

B. Ricart-Agrawala (message based)

 Process requests access by sending timestamped REQUEST to all others.

 Each other node replies with OK immediately if it is not interested or has lower
priority.
 Once requester receives OK from all, it enters critical section.
 On exit, it sends deferred OKs to nodes waiting.
 Avoids token but needs 2*(N-1) messages per critical section entry.

Clock / ordering (Lamport / Vector clocks)

Lamport timestamps: provide partial ordering; if A → B then timestamp(A) <

timestamp(B).

Vector clocks: capture causality more precisely; vector of size N, merged on events.

Consensus (overview)

Algorithms: Paxos, Raft — ensure agreement despite failures.

Steps generally: propose a value, gather votes/majority, commit value, replicate to

others.

4. Distributed file systems (overview)

Objectives: present a global file namespace, allow efficient access, scale to many clients
and servers, provide fault tolerance and consistency.

Important systems to explain: NFS, GFS, HDFS. For each: architecture, metadata flow,
read/write step flow, consistency model, strengths/weaknesses.

4a. NFS (Network File System)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Type: POSIX-like network filesystem; originally from Sun.

Architecture

Clients mount remote directories via NFS protocol.

Server exports filesystem; uses stateless protocol (older NFS versions).

Metadata: server stores file attributes.

Step-by-step: Read file (typical)

 Client issues LOOKUP to resolve pathname (may use client cache).

 Client sends READ RPC to server for file block(s).
 Server reads from local disk and returns data over network.
 Client may cache data and attributes for performance.

Step-by-step: Write file

 Client issues WRITE RPC.

 Server acknowledges (depending on sync/async policy).
 For durability, sync writes (fsync) force to disk.

Consistency

 Early NFS is weakly consistent due to client caching and stateless server; clients must
use cache invalidation timers (attribute TTL).
 NFSv4 introduced stateful operations and locking improvements.

Strengths

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

 Simple, widely deployed, integrates with POSIX.

Weaknesses
 Performance for large clusters limited; metadata bottleneck on server; semantics
around caching can be surprising.

4b. GFS (Google File System) — conceptual model

Type: Distributed file system for large data processing workloads (append-heavy, large
files).

Architecture

Master: holds metadata (namespace, file to chunk mapping, access control).

Chunkservers: store fixed-size chunks (typically 64 MB).

Clients: interact with master for metadata then directly with chunkservers for data.

Step-by-step: Read

 Client asks Master for chunk handle + chunkserver locations.

 Client chooses nearest/best chunkserver and reads chunk directly.
 Data may be read from the closest replica.

Step-by-step: Write / append

 Client asks Master for chunk locations and obtains primary replica.
 Client pushes data to all replicas (pipelined).
 Primary orders writes and coordinates replication; once completed, acknowledges.

Consistency model

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Relaxed: atomic append is provided as a primitive; concurrent writes may result in

multiple appends.

Strengths

 Designed for huge files and high throughput workloads (map-reduce). Master handles
metadata — efficient for many clients due to direct data transfers.

Weaknesses

 Single master is a metadata bottleneck (but master is optimized, and

checkpoints/replication mitigate).

4c. HDFS (Hadoop Distributed File System)

Type: Inspired by GFS, targeted for batch processing (Hadoop ecosystem).

Architecture

NameNode: metadata server (namespace, block locations).

DataNodes: store blocks (default 128 MB in modern HDFS).

Clients talk to NameNode for metadata, then to DataNodes for data.

Step-by-step: Read

 Client requests file metadata & block locations from NameNode.

 Client chooses DataNode (often nearest rack) and reads block.
 If DataNode fails, client retries another replica.

Step-by-step: Write
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

 Client requests NameNode to create file and get pipeline of DataNodes.

 Client sends data to first DataNode which forwards to the next, etc. (pipelined
replication).
 DataNodes write to disk and send acknowledgements back.

Consistency & semantics

HDFS is optimized for large, streaming reads and writes; files are typically write-
once, read-many — not suitable for low-latency small writes.

Strengths

Fault tolerant via replication, integrates with Hadoop jobs.

Weaknesses

NameNode is critical (single point of failure in older versions — newer HDFS has
high availability NameNode options).

5. Transparency issues

Definition: Transparency means hiding distribution complexity from users/programs.

Types and what they mean practically.

Types of transparency (with examples & implementation concerns)

1. Access transparency

 Same API for local and remote resources.

 Concern: handle network errors, latency differences.

2. Location transparency

 Resource name doesn’t reveal location.

 Concern: need mapping service or directory.

3. Migration transparency

 Users unaware if process/data moved.

 Concern: must handle state transfer, rebinds.

4. Replication transparency

 Multiple replicas hidden; system ensures consistency.

 Concern: must reconcile divergent replicas and choose freshness.

5. Concurrency transparency

 Multiple users access resources without interference.

 Concern: must implement locking or atomic ops.

6. Failure transparency

 Failures are hidden or masked (system retries, failover).

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

 Concern: complete masking may be impossible; partial masking acceptable.

Tradeoffs

Higher transparency → simpler programming model but more complex and

potentially less efficient system internals.

Partial transparency often chosen: expose some information (e.g., locality hints)
to improve performance.

6. Fault tolerance

Goal: continue service despite hardware/software failures; preserve correctness and

availability.

Failure models

Crash failures: node stops responding.

Omission failures: lost messages.

Byzantine failures: arbitrary (malicious) behavior.

Network partitions: groups of nodes cannot talk to others.

Step-by-step techniques for fault tolerance

Redundancy

Replication: multiple copies of data/services (synchronous vs asynchronous

replication).

Diversity: different implementations to avoid common bugs (less common).

Failure detection

Heartbeats, timeouts, watchdogs.

Tradeoff: shorter timeouts detect fast but risk false positives.

Recovery

Restart: restart failed process on same or different node.

State transfer / checkpointing: periodically save state so process can

resume.

Replay logs: use transaction logs to rebuild state.

Reconfiguration

Update routing/metadata to exclude failed nodes.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Elect a new leader if the leader fails (e.g., ZooKeeper, Raft).

Consensus for correctness

Use Paxos/Raft to agree on committed operations in presence of failures

(requires majority).

Step flow (Raft simplified):

Leader election if no leader

Client sends command to leader.

Leader appends command to log and replicates to followers.

Once majority acknowledges, leader commits and applies the

command.

Leader replies to client.

Data durability

Write-ahead logs, synchronous disk writes for critical meta-data.

Replication across racks/data centers for availability in case of site failure.

Practical example: HDFS fault tolerance

Data replicated (default 3 replicas across racks).

NameNode monitors DataNode heartbeats.

If DataNode fails, NameNode re-replicates its blocks to maintain replication factor.

Clients retry reading from other replicas.

Design tradeoffs

Availability vs consistency (CAP theorem): in partition, a system must choose

between consistency or availability.

Performance vs durability: synchronous replication ensures durability but

increases latency.

Quick comparison table (short)

NFS: POSIX, good for general files, less suited for very large data clusters.

GFS: optimized for large files, high throughput, relaxed consistency (Google
workloads).

HDFS: GFS-like for Hadoop, write-once/read-many, strong replication &

ecosystem.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

How to study / exam tips (stepwise)

For each topic, draw architectures (clients, master/NameNode,

chunkservers/DataNodes).

Write one read & one write flow step by step for each FS (NFS, GFS, HDFS).

Practice short answers: define transparency types and give one implementation
challenge for each.

For algorithms (scheduling, synchronization), be able to list pros/cons and message

complexity (e.g., Ricart-Agrawala uses 2(N−1) messages).

For fault tolerance, memorize failure models and which systems tolerate which
kinds (e.g., HDFS tolerates DataNode crashes via replication; NameNode needs
HA config)

If you want, I can:

Convert this into a printable one-page summary or mind map.

Produce step-by-step diagrams for any single part (e.g., GFS read/write pipeline) —
tell me which one and I’ll draw the exact sequence.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT - V

Security and Trust in Operating Systems: Access control models: DAC, MAC, RBAC-
OS hardening techniques, sandboxing, SELinux, AppArmor-Secure boot, rootkit detection,
trusted execution environments

Security and Trust in Operating Systems

Operating Systems (OS) must ensure confidentiality, integrity, and availability (CIA) of
data, programs, and system resources. Security is enforced using access controls,
authentication, authorization, monitoring, auditing, and trusted execution
mechanisms.

Access Control Models

Access control defines who (subject) can access what (object) and how (permission).

A. Discretionary Access Control (DAC)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Feature Explanation
Ownership The owner of a resource controls access
Flexibility High (users can grant permissions)
Example File permission in Windows, Linux (chmod, ACL)
Risk Privilege propagation, Trojan attacks

Steps in DAC

Each object has an owner.

Owner decides permission for other users/groups.

System checks access control list (ACL).

Access allowed or denied based on permissions.

B. Mandatory Access Control (MAC)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Feature Explanation
Ownership Controlled by system/security policy, not user
Used in Military, government, classified systems
Example Bell-LaPadula (Confidentiality), Biba (Integrity)
Labeling Every user & object has security label

Steps in MAC

Objects and subjects are assigned security classifications (Top-secret, secret).

Access granted using security rules, not owner choice.

Example Rules:

No read up (cannot read higher classification)

No write down (to prevent leakage)

C. Role-Based Access Control (RBAC)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Feature Explanation
Principle Access based on roles, not individuals
Example Admin, Manager, Analyst roles in enterprise
Benefit Easy to scale for organizations

Steps in RBAC

Define roles (Admin, HR, Guest, Auditor).

Assign permissions to roles.

Assign users to roles.

Users inherit permissions via roles.

OS Hardening Techniques

Hardening means reducing attack surface and removing vulnerabilities.

Step-by-step OS Hardening

Disable unnecessary services/ports

Remove unused software

Apply security patches/updates

Configure firewall and IDS/IPS

Strong authentication policies

Enforce least privilege & access control

Enable audit logging & monitoring

Use encryption (disk, file, network)

Sandboxing

Sandboxing isolates applications so that their actions do not affect the rest of the system.

How Sandboxing Works (Steps)

Application runs in isolated environment.

Limited access to file system, network, kernel.

Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Any malicious code stays inside sandbox.

Sandbox is destroyed after program ends.

Examples: Browser sandboxes, VirtualBox, Docker, JVM sandbox, Android app sandbox

SELinux (Security-Enhanced Linux)

| Type | MAC-based Linux security module |

| Developed by | NSA |
| Purpose | Strong, fine-grained mandatory access control |

How SELinux works (Steps)

Assign labels to files, processes, ports (context).

Define policies using type enforcement, role rules.

Kernel checks every access request.

Denies access if policy does not explicitly allow.

Modes: Enforcing, Permissive, Disabled

AppArmor

Another Linux security framework.

| Compared to SELinux | Easier to configure |

| Control Type | Path/Program-based MAC |
| Use Cases | Ubuntu, SUSE systems |

Steps in AppArmor

Profiles created for each application.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Define allowed file paths, capabilities, network access.

Kernel enforces rules during execution.

Secure Boot

Ensures only trusted & verified software loads during system startup.

How Secure Boot Works (Steps)

System firmware (UEFI) contains trusted cryptographic keys.

Only firmware-signed bootloaders are allowed to execute.

Bootloader verifies OS kernel signature.

Kernel verifies modules/drivers.

If any stage fails → boot halted to prevent malware booting.

Rootkit Detection

Rootkits hide malicious activity by modifying OS components.

Detection Methods

Integrity checking – compare system files using tools (Tripwire, AIDE).

Kernel-level scanning – chkrootkit, rkhunter.

Behavior monitoring – abnormal connections, privilege escalation.

Boot from trusted media and scan offline (because live OS may be compromised).

Trusted Execution Environments (TEE)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

| Purpose | Secure isolated hardware execution |

| Example | Intel SGX, ARM TrustZone, TPM |
| Protection | Prevents OS, hypervisor, malware from accessing secrets |

TEE Execution Steps

Application places sensitive code & data inside secure enclave.

CPU creates isolated secure memory region.

Encrypted memory prevents external access.

After execution, data remains secure or wiped.

Final Exam-Ready Summary Chart

Topic Key Idea Example

DAC Owner decides access chmod, ACL
MAC System-enforced policy Military, SELinux
RBAC Role-based permissions Enterprise apps
Hardening Reduce attack surface Patching, disabling services
Sandbox Isolate execution Browser sandbox
SELinux Label & policy-based MAC RHEL, Fedora
AppArmor Profile-based MAC Ubuntu
Secure Boot Signed boot chain UEFI
Rootkit Detection Detect hidden malware chkrootkit
TEE Hardware isolated execution Intel SGX

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT - VI

Real-Time and Embedded Operating Systems: Real-time scheduling algorithms (EDF,

RM)-POSIX RT extensions, RTOS architecture-TinyOS, FreeRTOS case studies

1. Real-Time Operating Systems (RTOS) Basics

A Real-Time Operating System ensures tasks meet timing deadlines.

Types of real-time systems:

Hard real-time → Missing deadline = system failure (e.g., flight control).

Firm real-time → Occasional misses tolerated, but reduce quality.

Soft real-time → Deadlines important but not critical (e.g., multimedia).

Key features of RTOS:

Deterministic scheduling

Low interrupt latency

Priority-based preemption

Predictable interprocess communication (IPC)

Minimal jitter

2. Real-Time Scheduling Algorithms

2.1 Rate Monotonic Scheduling (RMS or RM)

Type: Static, priority-driven, fixed-priority algorithm.

Priority rule: The shorter the task period, the higher its priority.

Assumptions

Tasks are periodic

Independent
Downloaded by Jincy Thenisha (jincyj1411@[Link])
 lOMoARcPSD|61528447

Preemptive

Deadline = period

Schedulability Test

For n tasks with CPU utilization U:

[
U = \sum_{i=1}^{n} \frac{C_i}{T_i}
]

System is schedulable if:

[
U \le n(2^{1/n}-1)
]

As n → ∞, limit = 0.693 (≈ 69%).

Pros

Very simple

Optimal for fixed priority systems

Cons

Not optimal overall

Lower CPU utilization compared to EDF

2.2 Earliest Deadline First (EDF)

Type: Dynamic scheduling.

Priority rule: Task with the earliest deadline gets the highest priority.

Schedulability Test

A set of periodic tasks is schedulable if:

[
U = \sum_{i=1}^{n} \frac{C_i}{T_i} \le 1
]

i.e., 100% CPU utilization is possible.

Pros

Optimal among dynamic schedulers

Maximizes CPU utilization

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Cons

More overhead (frequent priority recalculation)

Harder to implement on small embedded systems

3. POSIX Real-Time Extensions (POSIX.1b)

POSIX RT extensions give UNIX-like systems deterministic behavior.

Key Features:

1. Real-Time Scheduling

SCHED_FIFO – Fixed priority FIFO

SCHED_RR – Round-robin with timeslice

SCHED_OTHER – Default time-sharing

SCHED_DEADLINE (Linux extension) – EDF-based scheduling

2. Real-Time Signals

Faster and queueable

Prioritized signal delivery

3. High-Resolution Timers

APIs:

clock_gettime()

timer_create(), timer_settime()

Used for sub-millisecond timing.

4. Memory Locking

Prevents paging delays:

mlock(), mlockall()

5. Message Queues / Semaphores

Deterministic IPC:

mq_open(), mq_send()

sem_init(), sem_wait()

4. RTOS Architecture

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

A typical RTOS has:

1. Microkernel / Kernel

Task scheduling

Context switching

Interrupt handling

Synchronization (mutex, semaphores)

Memory management (deterministic)

2. Task / Process Management

Priority-based preemption

Dual-mode operation: ISR and tasks

Ready queues for different priorities

3. Inter-Task Communication

Message queues

Mailboxes

Semaphores

Event flags

4. Memory Management

Static allocation preferred

Predictable heap (fixed-size blocks)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

5. Device Drivers

Lightweight, low-latency

ISR + deferred handling

[Link]
TinyOS is an open-source, component-based operating system specifically designed
for resource-constrained devices like those found in wireless sensor networks
(WSNs). Its architecture emphasizes minimal resource usage and an event-driven
execution model.

Here are the key architectural elements of TinyOS:

Component-Based Architecture:
TinyOS applications are built by composing reusable software components. These
components are written in nesC, an extension of C, and interact through well-defined
interfaces.
Modules: These are the basic building blocks, containing application logic and device
drivers. They implement interfaces and provide functionality.
Configurations: These "wire together" modules by connecting their interfaces, creating a
complete application. A full TinyOS application is always a configuration.
Event-Driven Execution:
TinyOS primarily operates on an event-driven model.
Commands: These are requests issued by one component to another to perform a service.
Events: These are signals generated by components to indicate the completion of a service or
the occurrence of an external happening (e.g., a sensor reading).
Tasks: These are used for intra-component concurrency, allowing a component to perform
operations without blocking the main event loop.
Scheduler:
A simple, non-preemptive scheduler manages the execution of tasks and event
handlers. It ensures that tasks are run to completion before other tasks or event handlers are
processed.
Static Memory Allocation:
To minimize overhead and ensure predictability in resource-constrained
environments, TinyOS utilizes static memory allocation. All components and their
associated data structures are allocated at compile time.
Single Shared Stack:
TinyOS uses a single shared stack for all components and tasks, further reducing
memory footprint. There is no separation between kernel space and user space.
Minimal Abstractions:
TinyOS provides minimal abstractions for device and networking functionalities,
requiring applications to interact closer to the hardware for efficiency.
In essence, TinyOS's architecture is tailored for efficiency in WSNs by leveraging a
component-based design, an event-driven model, and strict resource management policies
like static memory allocation and a single shared stack.

5. Case Study: FreeRTOS

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Overview

Widely used open-source RTOS

Written in C

Extremely portable

Supports >40 architectures (ARM Cortex-M, RISC-V etc.)

Key Features

Preemptive priority-based scheduler

Supports EDF (via add-ons)

Tickless mode for low power consumption

Deterministic interrupts

IPC: queues, semaphores, mutexes

Memory allocation schemes (5 types)

Architecture

Kernel

Task Control Blocks (TCBs)

Scheduler

Port layer (architecture-dependent)

Strengths

Simple and lightweight

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Widely used in industry

Rich documentation

Weaknesses

Not as deterministic as some commercial RTOS

No built-in protection between tasks (unless using MPU version)

Summary Table

Feature RM EDF
Priority Fixed Dynamic
Utilization ~69% 100%
Overhead Low Higher
Complexity Simple Complex
Suitability Small RTOS General RTOS

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT - VII
Edge and Cloud OS: Future Paradigms: Serverless OS, unikernels, lightweight OS for
edge computing-Mobile OS internals (Android, iOS)-OS for quantum and neuromorphic
computing (intro)

1. Edge and Cloud OS: Future Paradigms

Modern distributed systems rely on specialized operating systems to support cloud-native,

serverless, and edge computing environments. These OS paradigms focus on scalability,
isolation, ultra-low resource usage, and hardware specialization.

2. Serverless OS

Definition

A serverless OS provides an execution environment where applications run as functions

(FaaS) without managing servers. The OS is optimized for:

extremely fast startup (millisecond or microsecond cold start)

isolation between functions

automatic scaling

Key Characteristics

Function-level isolation (sandboxing via microVMs or containers)

On-demand execution (spin-up/spin-down)

Stateless computing model

Distributed resource management

Examples

AWS Firecracker (microVM-based serverless OS)

Google gVisor (sandboxing for serverless containers)

Cloudflare Workers Runtime

Advantages

Minimal overhead

Strong security via microVM isolation

Elastic scaling

Challenges

Cold-start latency

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Debugging complexity

Limited long-running state

3. Unikernels

Definition

A unikernel is a specialized single-address-space machine image that includes:

only the necessary OS components

the application code

compiled into one minimal executable

Characteristics

Library OS approach (application links with only needed OS libraries)

Extremely small footprint (KB–MB)

Near-instant boot times (milliseconds)

High security: fewer attack surfaces

Runs directly on hypervisors (Xen/KVM)

Examples

MirageOS

IncludeOS

OSv

Unikraft

Use Cases

Cloud microservices

High-performance network appliances

Serverless platforms

4. Lightweight OS for Edge Computing

Edge devices require OSes that are:

resource-efficient

energy-aware

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

real-time capable

secure and reliable

Key Features

Minimal memory usage

Low boot time

Real-time scheduling

Security hardening

Support for heterogeneous hardware (MCUs, SoCs)

Examples

ARM Mbed OS – IoT devices

RIOT OS – WSN and IoT

Contiki-NG – IPv6, 6LoWPAN

Zephyr OS – Linux Foundation RTOS for edge

Amazon FreeRTOS – IoT microcontroller devices

5. Mobile OS Internals

5.1 Android Internals

Android is based on Linux kernel with modifications for mobile use.

Android Architecture Layers

Linux Kernel

Drivers for binder IPC, power mgmt, display, audio

Hardware Abstraction Layer (HAL)

Standard interface for sensors, camera, GPS

Android Runtime (ART)

Ahead-of-Time (AOT) & Just-in-Time (JIT) compiler

Native Libraries

OpenGL, WebKit, SQLite, SSL

Application Framework

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Activity Manager

Window Manager

Telephony Manager

Applications

Written in Java/Kotlin

Key Components

Binder IPC – core communication mechanism

Zygote – process launcher for fast app startup

SELinux – security sandbox

Activity/Service/ContentProvider/BroadcastReceiver – app components

5.2 iOS Internals

iOS is based on XNU kernel, a hybrid of Mach + BSD.

iOS Architecture Layers

Core OS

XNU kernel, networking, file system (APFS), drivers

Core Services

Foundation, CloudKit, GCD

Media Layer

Metal, CoreAudio, CoreAnimation

Cocoa Touch

UIKit, Multitouch, Notification Center

Applications

Swift/Objective-C apps

Key Characteristics

App sandboxing (per-app sandbox)

Grand Central Dispatch (GCD) for concurrency

Secure Enclave for crypto

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Tight hardware-software integration

6. OS for Quantum Computing (Intro)

Quantum systems require new OS concepts due to qubits, superposition, and decoherence.

Key Requirements

Quantum circuit scheduling

Qubit resource management

Error correction & noise management

Hybrid classical/quantum execution

Low-level control of quantum gates

Examples (current research prototypes)

IBM Qiskit Runtime

Google Cirq stack

Microsoft Azure Quantum OS concepts

Xanadu PennyLane

Challenges

No standard memory model

Limited qubit stability

Lack of universal instruction sets

Quantum OS today are more like runtime environments than traditional OS.

7. OS for Neuromorphic Computing (Intro)

Neuromorphic hardware imitates neurons and synapses using spiking neural networks
(SNNs).

Key OS Requirement

Event-driven processing (spike-based)

Asynchronous parallelism

Energy-efficient task scheduling

Mapping neural networks onto neuromorphic cores

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Examples

Intel Loihi – NxOS (research OS for neuromorphic chips)

IBM TrueNorth – Compass toolkit

SpiNNaker OS (event-driven parallel runtime)

Challenges

Programming models differ from Von Neumann

Lack of unified frameworks

Data representation through spikes, not bytes

Neuromorphic OS are essentially brain-inspired runtime systems.

8. Summary Table

Technology Key Idea Benefit Examples

Serverless OS Function-driven execution Elastic scaling Firecracker, gVisor
Single-purpose minimal MirageOS,
Unikernels Ultra-fast, secure
OS IncludeOS
Zephyr, Contiki,
Edge OS Lightweight, real-time Energy-efficient
Mbed
Android OS Linux-based mobile OS Large ecosystem Android
iOS XNU hybrid kernel Secure, optimized iPhone/iPad
Quantum OS Qubit + classical control Quantum computation Qiskit Runtime
Neuromorphic Brain-like
Spike-based processing Loihi NxOS
OS performance

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

2 marks
UNIT I

1. What are multithreading models?

Multithreading models describe how user threads map to kernel threads. The three
common models are many-to-one, one-to-one, and many-to-many, each offering
different levels of concurrency and flexibility.

2. Differentiate between many-to-one and one-to-one threading models.

Many-to-one maps multiple user threads to a single kernel thread (no true parallelism).
One-to-one creates a kernel thread for each user thread, enabling parallel execution on
multicore CPUs.

3. What is a thread pool?

A thread pool is a collection of pre-created worker threads that execute tasks from a queue,
reducing thread creation overhead and improving resource utilization.

4. What is context switching?

Context switching is the process where the CPU saves the state of a running thread/process
and loads the state of another, enabling multitasking.

5. Mention two factors that make context switching expensive.

Saving and restoring registers, program counter, and memory maps

Cache invalidation and TLB flushing during switch

6. What is a semaphore?

A semaphore is a synchronization primitive used to control access to shared resources

using counters, preventing race conditions and ensuring mutual exclusion.

7. Define binary semaphore.

A binary semaphore has only two values (0 and 1) and is used for mutual exclusion, similar
to a lock.

8. What is a monitor?

A monitor is a high-level synchronization construct that combines mutual exclusion with

condition variables, ensuring only one thread accesses critical code at a time.

9. What are lock-free data structures?

Lock-free data structures allow multiple threads to operate without mutual exclusion locks,
ensuring progress using atomic operations like CAS (Compare-And-Swap).

10. Mention two advantages of lock-free data structures.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Avoid deadlocks and priority inversion

Better performance under high concurrency

11. What is CPU affinity?

CPU affinity binds a thread/process to a specific CPU/core, improving cache locality and
performance in multicore systems.

12. What is load balancing in multicore scheduling?

Load balancing distributes tasks across CPU cores evenly to avoid idle cores and improve
overall throughput.

13. What is gang scheduling?

Gang scheduling runs related threads or processes simultaneously on separate cores to

reduce synchronization latency.

14. Define spinlock.

A spinlock is a lock where a thread repeatedly checks the lock variable until it becomes
free, suitable for short critical sections in multicore systems.

15. What is priority inversion?

Priority inversion occurs when a high-priority thread is blocked by a lower-priority thread

holding a required lock.

16. What is priority inheritance?

In priority inheritance, a low-priority thread temporarily inherits the higher priority of a

blocked thread to prevent priority inversion.

17. What is a race condition?

A race condition occurs when multiple threads access shared data concurrently, and the
final outcome depends on the timing of execution.

18. What is a condition variable?

A condition variable allows a thread to sleep until another thread signals a condition,
commonly used with monitors and mutexes.

19. What is a lightweight process (LWP)?

An LWP is a kernel-level thread that supports user-thread execution, serving as a bridge

between user-level and kernel-level scheduling.

20. What is thread migration?

Thread migration is the movement of a thread from one CPU/core to another, typically
performed by the scheduler for load balancing.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

PART B

Question 1

Explain the different multithreading models used in operating systems. Discuss the
advantages and disadvantages of each model.

Keywords: Many-to-One, One-to-One, Many-to-Many, Two-Level, advantages,

disadvantages

Question 2

What are thread pools? Explain how thread pools improve the efficiency of
multithreaded programs. Describe typical use cases where thread pools are beneficial.

Keywords: Thread creation overhead, task queue, worker threads, server applications

Question 3

Describe the process of context switching in operating systems. Differentiate between

context switching in user-level threads and kernel-level threads. Discuss the impact of
context switching on system performance.

Keywords: Saving/restoring context, registers, program counter, user-level vs kernel-level

threads, overhead

Question 4

Discuss the synchronization problems that arise in multithreaded systems. Explain

how semaphores, monitors, and lock-free data structures help solve these
synchronization issues.

Keywords: Race conditions, deadlocks, starvation, semaphores, monitors, lock-free data

structures, atomic operations

Question 5

Explain CPU scheduling strategies in multi-core systems. Discuss challenges faced in

scheduling threads on multiple cores and techniques such as load balancing and
processor affinity to address these challenges.

Keywords: Per-core vs global scheduling, load balancing, processor affinity, real-time

scheduling

Question 6 (Integrated question)

a) Compare and contrast the various multithreading models.

b) Explain the role of synchronization mechanisms like semaphores and monitors in
thread management.
c) Describe how CPU scheduling is implemented in multi-core systems to achieve
efficient process management.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

UNIT II

1. Define virtual memory.

Virtual memory is a memory management technique that provides an application with a

large, uniform address space by using both RAM and secondary storage.

2. What is demand paging?

Demand paging is a scheme where a page is brought into main memory only when it is
referenced, reducing initial loading time.

3. What is a page fault?

A page fault occurs when a process tries to access a page that is not currently loaded in
RAM, triggering the OS to fetch it from disk.

4. Write any two page replacement algorithms.

Examples: FIFO, LRU, Optimal, Clock (Second-Chance), LFU.

5. What are huge pages?

Huge pages are large-size memory pages (e.g., 2 MB, 1 GB) that reduce TLB misses and
improve performance for memory-intensive applications.

6. Define TLB (Translation Lookaside Buffer).

TLB is a cache that stores recent virtual-to-physical address translations to speed up

memory access.

7. What is NUMA?

NUMA (Non-Uniform Memory Access) is a memory architecture where memory access

time depends on the memory’s proximity to a CPU node.

8. What is first-touch memory allocation in NUMA systems?

The page is allocated on the NUMA node of the CPU that first accesses it, improving
locality.

9. What is thrashing?

Thrashing occurs when excessive page faults cause the system to spend more time
swapping pages than executing processes.

10. What is cgroups in Linux?

cgroups (control groups) is a Linux kernel feature that limits, measures, and isolates CPU,
memory, and I/O resources for processes/containers.

11. What are resource limits in cloud-native environments?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

They are constraints (CPU/memory limits and requests) set for containers to control
resource usage and ensure isolation.

12. What is horizontal pod autoscaling (HPA)?

HPA automatically increases or decreases the number of running container replicas based
on metrics like CPU usage.

13. Define swapping.

Swapping is the process of moving an entire process or its memory pages between RAM
and disk to free space.

14. What is the role of the page table?

The page table stores mappings between virtual addresses and physical addresses.

15. What is memory interleaving?

Interleaving distributes memory pages across multiple NUMA nodes to balance load and
minimize latency.

PART B

Question 1

Explain the concept of virtual memory and demand paging in modern operating
systems. How does demand paging improve memory utilization?

Keywords: Virtual memory, address translation, page fault, demand paging

Question 2

Describe various page replacement policies used in operating systems. Compare the
performance of FIFO, LRU, and Optimal page replacement algorithms.

Keywords: Page replacement, FIFO, LRU, Optimal, page fault rate

Question 3

What are Huge Pages in memory management? Discuss their advantages and
challenges in modern operating systems.

Keywords: Huge pages, page size, TLB efficiency, memory fragmentation

Question 4

Explain the concept of NUMA (Non-Uniform Memory Access) and how NUMA-
aware memory management improves performance in multi-processor systems.

Keywords: NUMA architecture, memory locality, latency, scheduling

Question 5

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Discuss resource allocation strategies in cloud-native environments. How do modern

operating systems manage memory and CPU resources efficiently in such
environments?

Keywords: Resource allocation, containers, virtualization, dynamic scaling

Question 6 (Integrated question)

a) Describe demand paging and the importance of page replacement policies.

b) Explain Huge Pages and their role in memory management.
c) Discuss NUMA-aware memory management and its benefits in multi-core systems.

UNIT III

1. What is Virtualization?

Virtualization is the technique of creating a virtual version of hardware or OS resources so

multiple operating systems can run independently on the same physical machine.

2. What is a Hypervisor?

A hypervisor is a software layer that creates and manages virtual machines by abstracting
the underlying hardware.

3. Type I Hypervisor

A Type-I hypervisor (bare-metal) runs directly on the hardware and manages guest OSes.
Example: Xen, VMware ESXi.

4. Type II Hypervisor

A Type-II hypervisor runs on top of a host operating system and provides virtualization as
an application.
Example: VirtualBox, VMware Workstation.

5. KVM

KVM (Kernel-based Virtual Machine) is a Linux kernel module that converts Linux into a
Type-I hypervisor using hardware virtualization features like VT-x/AMD-V.

6. QEMU

QEMU is an emulator and virtualizer capable of full system emulation and, when
combined with KVM, offers near-native VM performance.

7. Xen Hypervisor

Xen is a Type-I hypervisor that supports paravirtualization and hardware virtualization,

using a privileged domain called Dom0 to manage guest domains.

8. Containerization

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Containerization is an OS-level virtualization technique where applications run in isolated

user-space environments using the same host kernel.

9. Docker

Docker is a container platform that uses images, namespaces, and cgroups to deploy
applications in lightweight, portable containers.

10. LXC (Linux Containers)

LXC is a system container technology that uses Linux kernel features to run full Linux
systems in isolated environments without a full hypervisor.

11. systemd-nspawn

systemd-nspawn is a lightweight container tool provided by systemd to run isolated Linux

environments or OS images in a sandboxed container.

12. OS-level Virtualization

OS-level virtualization creates isolated process environments (containers) using a shared

kernel, enabling fast and lightweight virtualization.

13. Linux Namespaces

Namespaces isolate system resources like process IDs, networks, mounts, and hostnames
so each container has its own independent environment.

14. cgroups

Control groups (cgroups) manage and limit resource usage—such as CPU, memory, and
I/O—of processes in Linux containers.

15. Difference between VM and Container

VMs virtualize complete hardware and run their own OS, while containers share the host
kernel and isolate processes, making them more lightweight.

PART B

Question 1

Explain the difference between Type I and Type II hypervisors. Discuss their use
cases and examples.

Keywords: Type I (bare-metal), Type II (hosted), KVM, Xen, QEMU

Question 2

Describe the architecture and working of KVM and QEMU as virtualization solutions.
How do they complement each other?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Keywords: Kernel-based Virtual Machine (KVM), QEMU as emulator, hardware

acceleration

Question 3

What is containerization? Explain how Docker and LXC provide container-based

virtualization. Highlight the differences between containers and traditional virtual
machines.

Keywords: Containers, isolation, lightweight, Docker, LXC, shared kernel

Question 4

Discuss OS-level virtualization and namespaces. How does systemd-nspawn utilize

namespaces for containerization?

Keywords: OS-level virtualization, namespaces (PID, network, mount), systemd-nspawn

Question 5

Compare and contrast virtualization with containerization in terms of performance,

resource utilization, and isolation. Give real-world examples of each.

Keywords: Virtual machines vs containers, overhead, startup time, security

Question 6 (Integrated question)

a) Define hypervisors and differentiate between Type I and Type II.

b) Explain containerization with examples like Docker and LXC.
c) Describe OS-level virtualization and how namespaces help achieve container
isolation.

UNIT IV

TWO MARKS

1. What is a Distributed Operating System?

A Distributed Operating System manages a collection of independent computers and

presents them as a single, unified system to the user, providing resource sharing,
communication, and synchronization.
2. What is Distributed Scheduling?

Distributed scheduling allocates processes to different nodes in a network to balance load,

reduce response time, and improve overall system performance.
3. What is Communication in Distributed Systems?

Communication is the exchange of data between processes on different nodes using

message passing or remote procedure calls (RPC).
4. What is Synchronization in Distributed Systems?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Synchronization ensures the correct ordering of events and coordinated execution across
distributed nodes using logical clocks, vector clocks, or mutual exclusion algorithms.
5. What is a Distributed File System (DFS)?

A DFS allows users to access and manage files stored on multiple machines as if they were
local files, providing transparency and fault tolerance.
6. What is NFS (Network File System)?

NFS is a DFS protocol that allows transparent access to remote files over a network,
commonly used in UNIX/Linux systems.
7. What is GFS (Google File System)?

GFS is a distributed file system designed for large-scale data storage, optimized for high
throughput, reliability, and fault tolerance.
8. What is HDFS (Hadoop Distributed File System)?

HDFS stores very large files across multiple nodes with replication for fault tolerance,
commonly used in Big Data applications.
9. What is Transparency in DFS?

Transparency hides the complexity of a distributed system from the user, including file
location, replication, access, and migration.

10. What is Fault Tolerance in DOS/DFS?

Fault tolerance allows the system to continue operation despite hardware or software
failures using replication, checkpointing, and recovery protocols.

PART B

Question 1

Explain the concepts of distributed scheduling, communication, and synchronization

in Distributed Operating Systems. Discuss the major challenges involved in
coordinating distributed processes.
Keywords: load balancing, message passing, RPC, logical clocks, mutual exclusion,
deadlocks, latency.

Question 2

Describe the architecture and working of Distributed File Systems with suitable
examples. Explain the design principles and features of NFS, GFS, and HDFS.
Compare their approaches to data storage, metadata handling, and fault tolerance.
Keywords: client–server model, metadata server, chunk servers, replication, NameNode,
DataNode.

Question 3

What is transparency in distributed systems? Explain different types of transparency

with examples. Discuss how fault tolerance is achieved in distributed environments
through replication, checkpointing, and reconfiguration.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Keywords: location, migration, concurrency, replication transparency, failure transparency,

reliability.

UNIT V

1. What is Access Control in OS Security?

Access control is a mechanism that restricts users’ or processes’ access to system resources
based on defined security policies.
Reference: Silberschatz et al., Operating System Concepts, 10th Edition.

2. What is DAC (Discretionary Access Control)?

DAC allows the owner of a resource to decide who can access it, typically using access
control lists (ACLs) or file permissions.
Reference: Stallings, Operating Systems: Internals and Design Principles, 9th Edition.

3. What is MAC (Mandatory Access Control)?

MAC enforces access policies defined by the system, not the user, based on security labels
and classification levels (e.g., Confidential, Secret).
Reference: Silberschatz et al., Operating System Concepts, 10th Edition.

4. What is RBAC (Role-Based Access Control)?

RBAC assigns permissions to roles instead of users. Users acquire access rights based on
their assigned role.
5. What is OS Hardening?

OS hardening is the process of securing an operating system by reducing vulnerabilities,

disabling unused services, and applying patches.
6. What is Sandboxing?

Sandboxing isolates applications in a restricted environment to prevent them from affecting

the system or accessing sensitive resources.
7. What is SELinux?

SELinux (Security-Enhanced Linux) implements Mandatory Access Control (MAC) in

Linux, enforcing security policies using labels and rules.
8. What is AppArmor?

AppArmor is a Linux security module that confines applications to a restricted set of

resources using profile-based Mandatory Access Control.

9. What is Secure Boot?

Secure Boot is a firmware feature that ensures only digitally signed and trusted OS boot
loaders and kernels are executed.

10. What is Rootkit Detection?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Rootkit detection identifies and removes malicious software that hides in the OS kernel or
processes to maintain unauthorized access.

11. What is a Trusted Execution Environment (TEE)?

A TEE is a secure area of the main processor that ensures code and data are protected from
unauthorized access and tampering.

PART B

Question 1 (13 Marks)

Explain the different access control models used in operating systems. Discuss
Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Role-
Based Access Control (RBAC) with suitable examples. Compare their strengths and
limitations.

Question 2 (13 Marks)

Describe OS hardening techniques in detail. Explain how methods such as patch

management, minimizing attack surface, disabling unused services, secure
configuration, and logging help strengthen system security. Provide practical
examples.

Question 3 (13 Marks)

What is sandboxing in operating systems? Explain how SELinux and AppArmor

enforce security policies through sandboxing and mandatory access control. Compare
their architecture, policy enforcement mechanisms, and real-world usage.

Question 4 (13 Marks)

Discuss the importance of secure boot, rootkit detection, and trusted execution
environments (TEE) in building a secure OS. Explain how these mechanisms protect
the system from low-level attacks and maintain system integrity. Include suitable
diagrams.

UNIT VI

1. What is a Real-Time Operating System (RTOS)?

A Real-Time OS is designed to provide predictable and deterministic response times to

events, ensuring tasks complete within specified deadlines.
2. What is an Embedded Operating System?

An Embedded OS is tailored to run on embedded devices with limited resources, optimized

for performance, reliability, and low power consumption.
3. What is Rate-Monotonic Scheduling (RM)?

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

RM is a fixed-priority real-time scheduling algorithm where tasks with shorter periods are
given higher priority.
4. What is Earliest Deadline First (EDF)?

EDF is a dynamic priority scheduling algorithm where tasks with the earliest deadlines are
scheduled first.
5. What are POSIX Real-Time Extensions?

POSIX RT extensions provide APIs for real-time features like real-time signals, timers,
and threads, enabling deterministic behavior in UNIX/Linux systems.
[Link] is RTOS Architecture?

An RTOS architecture typically includes a kernel, task scheduler, inter-task

communication, and I/O management, optimized for real-time constraints.
7. What is TinyOS?

TinyOS is an open-source, component-based RTOS designed for wireless sensor networks

and embedded systems with minimal resource usage.
8. What is FreeRTOS?

FreeRTOS is a popular open-source RTOS for microcontrollers, providing multitasking,

scheduling, and real-time APIs for embedded applications.
9. Difference between RM and EDF (brief)

RM: Fixed-priority; shorter-period tasks have higher priority.

EDF: Dynamic-priority; tasks with earliest deadlines get scheduled first.

Reference: Liu & Layland, 1973.

10. Use Case of RTOS in Embedded Systems

RTOS is used in applications requiring precise timing and predictability, e.g., automotive
control systems, medical devices, and industrial automation.

PART B

Question 1 (13 Marks)

Explain real-time scheduling algorithms in detail. Discuss the principles, working,

and schedulability analysis of Rate Monotonic (RM) and Earliest Deadline First (EDF)
scheduling. Compare their advantages and limitations in real-time systems.

Question 2 (13 Marks)

Describe POSIX real-time extensions. Explain the significance of real-time signals,

timers, priority scheduling, and asynchronous I/O in ensuring deterministic
performance in real-time applications. Provide suitable examples.

Question 3 (13 Marks)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Explain the architecture of a Real-Time Operating System (RTOS). Discuss key

components such as task management, interrupt handling, scheduling, inter-process
communication, memory management, and timing services with neat diagrams.

Question 4 (13 Marks)

Write a detailed note on TinyOS and FreeRTOS. Describe their architecture, features,
programming model, and use cases. Compare them in terms of flexibility, resource
usage, and suitability for embedded and IoT applications. Include a case study for
each.

UNIT VII

1. What is a Cloud Operating System?

A Cloud OS manages and abstracts cloud resources, providing virtualized infrastructure,

scalability, and multi-tenancy for users.
2. What is an Edge Operating System?

An Edge OS runs on edge devices close to data sources, optimized for low latency, real-
time processing, and limited resources.
3. What is a Serverless OS?

A serverless OS abstracts server management completely, allowing developers to run

functions on-demand without provisioning or managing servers.
4. What is a Unikernel?

A unikernel is a specialized, single-address-space OS image compiled with only the

necessary application components, providing minimal footprint and strong security.
5. What is a Lightweight OS for Edge Computing?

A lightweight OS is optimized for edge devices with minimal memory and CPU usage,
supporting real-time and energy-efficient operations.
6. What is Android OS?

Android is a Linux-based mobile OS with layered architecture including Linux kernel,

HAL, runtime (ART), application framework, and apps.
7. What is iOS?

iOS is Apple’s mobile OS with a layered architecture including Cocoa Touch, Media,
Core Services, Core OS, optimized for security, performance, and energy efficiency.
8. What is an OS for Quantum Computing?

Quantum OS manages quantum hardware and schedules quantum tasks, providing

abstractions for qubits and quantum algorithms.
9. What is an OS for Neuromorphic Computing?

Neuromorphic OS supports brain-inspired computing, managing spiking neural networks

and specialized hardware for energy-efficient AI.
10. Difference between Cloud OS and Edge OS (brief)

Cloud OS: Centralized, scalable, virtualized.

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Edge OS: Decentralized, low-latency, resource-constrained devices.

PART B

1. Explain in detail the concept of Serverless Operating Systems. Discuss architecture,

working, advantages, limitations, and real-world examples. Draw a neat diagram. (13
Marks)

2. What are Unikernels? Describe their architecture, working, features, advantages,

and challenges. Compare Unikernels with traditional OS and microVMs. (13 Marks)

3. Discuss the need for lightweight operating systems for edge computing. Explain
their design considerations, architecture, features, and use cases with suitable
examples. (13 Marks)

4. Explain the internal architecture of Android OS. Discuss the role of each layer
(Linux kernel, native libraries, Android Runtime, framework, applications) with a
clean diagram. (13 Marks)

5. With a neat diagram, explain the internal architecture of iOS. Discuss the XNU
kernel, Core OS, Core Services, Media Services, and Cocoa Touch layers. (13 Marks)

6. Write a detailed note on the OS requirements for Quantum Computing. Explain

the challenges, qubit scheduling, error correction, execution models, and existing
solutions. (13 Marks)

7. Describe Neuromorphic Computing Architecture and the need for a specialized OS.
Explain event-driven processing, SNN scheduling, memory organization, and real-
time execution. (13 Marks)

8. Compare Serverless OS, Unikernels, and Lightweight Edge OS in terms of

architecture, performance, security, and use cases. Provide examples and diagrams.
(13 Marks)

9. Explain how mobile operating systems like Android and iOS are optimized for
performance, security, and resource management. Compare their architectural
differences. (13 Marks)

10. Discuss future OS paradigms for emerging hardware platforms. Explain how OS
design will evolve for quantum processors, neuromorphic chips, edge devices, and
cloud-native systems. (13 Marks)

Downloaded by Jincy Thenisha (jincyj1411@[Link])

 lOMoARcPSD|61528447

Downloaded by Jincy Thenisha (jincyj1411@[Link])