CS 704DAdvanced Operating System

( Resource & Process Management)

Debasis Das

IT 703D Debasis Das

Resource and Process Management

Resource management Approaches

• Task Assignment approacho Tasks are assigned to suitable nodes

• Load balancing approacho Processes are distributed so as to balance load on

nodes• Load sharing approach

o Processes are distributed equitably, so that no node is idle while there is queue for some node

Features ofof Good Global Scheduling

• No a-priori knowledge about processes• Dynamic in nature• Quick decision making capability• Balanced system performance and scheduling

overhead• Stability• Scalability• Fault tolerance• Fairness of service

Task assignment Approach• Assumptions

o Process is already broken into taskso Amount of computation required by a task and speed

of processing at nodes are knowno Cost of processing at each node is knowno IPC costs between every pair of tasks are knowno Resource requirements of tasks, availability at each

node and precedence of tasks are knowno Reassignment of tasks generally not possible

Task assignment ApproachGoals

• Minimization of IPC costs• Quick turn around for a process• High degree of parallelism• Efficient utilization of system resources

Load Balancing Approach• Goal: Maximum throughput• Algorithms available

o Static vs. dynamic Average known performance taken into consideration rather than

instantaneous figureso Deterministic vs. probabilistic

A static approach. Processor assignment to a node is fixed.o Centralized vs. distributed

A dynamic method. A centralized server may decide assignments. K servers will make assignments in a decentralized approach

o Cooperative vs. non cooperative Dynamic assignment elements may work in isolation in the non-cooperative mode. In the

co-operative mode they share information so that a more uniform assignment can be made

Issues in Designing Load Balancing Algorithms

• Load estimation policy

o How the load on a node is estimated

• Process transfer policy

o Basis of executing a process locally or at a remote node

• State information exchange policy

o How state information should be exchanged

• Priority assignment policy

o Priority of local and remote processes at a node

• Migration limiting policy

o Total number of times a process may be migrated from one another node

Load Estimation policies• Load depends on parameters as follows

o No. of processes at the nodeo Resource demand of these active processeso Instruction mixes of these processeso Architecture and speed of the node’s processor

Process Transfer Policies• Static

o Predetermined threshold is considered depending on the processing capability

• Dynamico Threshold is calculated as a product of the average

workload of all nodes. State information is exchanged to determine the threshold at any time

o One may use a single threshold policy or the dual threshold policy

Location Policies• Once transfer policy is decided where to locate a process is decided by one

of the following methodso Threshold

Pick a node at random, check a threshold and then assign if under-loaded

o Shortest Pick p nodes at random, assign to the node with lightest node

o Bidding Each node has a manager and a contractor role. A node that needs

service broadcasts need. Contractors bid. Winning bidder gets the process

o Pairing Create pairs between two nodes that do balancing between them

Static Information Exchange Policies

• Periodic broadcastso Network traffic increases, not scalable, useless

information(no change) many a times• Broadcast when state changes

o Additionally, one can broadcast only when overloaded or under-loaded

• On-demand exchangeo Only when under-loaded or overloaded

• Exchange by pollingo Poll random nodes. Stop when a partner is found or

polling limit is reached

Priority Assignment policies• Priority assignment rules required for local as well

as remote processes• Rules used could be

o Selfish Local processes get higher priority

o Altruistic Remote processes get higher priority

o Intermediate Depending on no of local processes & remote processes.

Local processes get priority if more no. of local processes & vice versa

Migration limiting policies• Uncontrolled

o Any process arriving at a node is welcome. Can cause instability

• Controlledo Use migration count on a process to limit how many

times a process may be migrated. Some designers favor a migration count of 1. Some others favor a value >1 particularly for long tasks

Load-sharing approach• Issues in load-sharing algorithms

o Load estimation policieso Process transfer policieso Location policies

Sender-initiated location policies Receiver initiated location policy

o State information Exchange policies Broadcast when state changes Poll when state changes

Load Estimation Policies• All one needs to know is if a node is idle• There may be several processes running on current

distributed systems• CPU utilization may be a good estimator

Location Policies• Sender initiated policies

o A overloaded node may broadcast for a lightly loaded node or poll nodes

• Receiver initiated policieso Lightly loaded nodes broadcast that they can receive

processes or poll randomly for heavily loaded nodes to share load. A node is eligible to send a process only if sending that process does not get him below the threshold and make it lightly loaded.

State Information Exchange Policies

• Broadcast when state changeso State information request message is sent out only

when a node goes belo9w/above threshold• Poll when state changes

o Poll only when the state changes.

• In either case, location policy decides if the overloaded node or the under-loaded node initiates the action

Process Management• Manage processes such that all processing

resources are utilized in the best possible manner.• Important concepts in this regard,

o Processor allocation: which process goes to which processor

o Process migration: should the process be migrated to some other processor

o Threads: fine grained parallelism to better utilize resources

Process Migration• Issues

o Selection of a process to be migratedo Selection of destination nodeo Actual transfer of the process

• Actual time taken when the process is being transferred is “freezing time”, the process is stopped

• Preemptive and non-preemptive transferso Process migrated before it has started is non-preemptiveo Process migrated when it is in execution is preemptive, will need the

whole execution state to be transferred

Process MigrationDesirable Features

• Transparencyo Object access level: allows easy non preemptive migration if object

level(files, devices) is available. Processes can be initiated at any arbitrary node. Naming needs to be location independent

o System call and IPC level: system calls & IPC need to be system/location independent . This then can support pre-emptive migration

• Minimal Interference : minimal freezing time• Minimal residual dependencies: once a process migrates, there should not

be any dependency left in the source system• Efficiency: time & cost to be minimal• Robustness: other than failure of the current execution node, nothing else

should matter• Communication between co-processes of a job: if co-processes are

distributed they should be able to communicate freely

Process MigrationProcess Migration Mechanisms

• Migration activitieso Freezing on source node, restarting on destination

nodeo Transferring of process address spaceo Forwarding messages meant for the process migratedo Handling communication between co-operating

process

Freezing & Restart of Processes• Issues

o Immediate & delayed blocking of processeso Fast & slow I/O operationso Reinstating the process on destination nodeo Address space transfero Total freezingo Pre-transferringo Transfer on reference

Blocking of Processes• In preemptive migration, a snapshot of the process

is to be taken. This is to be restored at destinationo Blocking at source can take place only when

Process is not executing a system call, block immediately Process is executing a system call and sleeping at a

interruptible priority level, block immediately. Process is executing a system call and sleeping on non-

interruptible level waiting for a kernel event to occur, delay blocking until system call is complete.

Fast & Slow I/O Operations• Freezing occurs after fast I/O such as disk I/O are

completed.• Waiting for slow I/O such as terminal I/O may not be

feasible.• Some means of continuing slow I/O after migration

will be required• Information about open files

o A link to the open file is createdo A complete path name from the new node is created

Re-instating on Destination Node• A new empty process state is created on destination

node• In some implementations this may have a different

process id for a while• After the migration happens completely the id may

be changed to the original id and the original process deleted

• In some cases such as when slow I/O is kept open, special handling may be needed. System call may have to be executed again.

Address Space Transfer Mechanisms

• Processor state needs to be transferred. This includes I/O queues, I/O buffer contents, interrupt signals, etc as I/O state, process id, user and group identifier, files opened etc are other memory data required

• Process’s address space that includes code, data and stack

• Processor state memory is of the order of kilobytes while the process address space typically is in megabytes. There’s some flexibility in transferring address space

Transfer Mechanisms• Total freezing

o Source process is frozen until not only the process but also address space transfer is complete, takes a longer freeze time

• Pre-transferringo Address space transfer is completed before the

source process is frozen and migration completed• Transfer on reference

o Address space transfer takes place only when the restarted, migrated process makes reference to anywhere in the address space

Message Forwarding Mechanisms• Kinds of messages

o Messages that arrive after source process is frozen but the destination process has not started

o Message at source node after the process has started at destination nodeo Messages to the migrant process after the execution at destination has started

• Resending the message mechanismo Drop the message, let the senders retransmit messages again after locating the destination

process• Origin site mechanism

o Each node receiving message for processes on it, keep track of the migration and forward messages

• Link traversal mechanismo First type are located in a queue and forwarded along with address space. A link left at source node

lets the messages of type 2 &3 to be forwarded.• Link update mechanism

o System wide links are maintained. On completion of migration the links held by kernels of communicating processes are updated to point to the destination link.

Handling Co-processes• Disallowing separation of co-processes

o Disallow migration of a processes whose children are yet to complete

o When a process does migrate, ensure all the children go with it

• Home node or origin site concepto A home node is defined, all communications work

though this node. So that when separated they still can communicate. Network traffic increases though

Process Migrationin

Heterogeneous Systems• Main issue is different data representation on

machines• An external data representation is created• Floating point numbers are, typically, need the most

consideration in creating the representation. Following need to be considered very closelyo Exponent handlingo Mantissa handlingo Signed infinity and signed zero representations

Process MigrationAdvantages

• Reducing average response times of processes• Speeding up individual jobs• Gaining higher throughput• Utilizing resources effectively• Reducing network traffic• Improving system reliability• Improving system security

Threads• General

o Share an address space & open files, global variable, child processes, semaphores, signals, accounting information and other OS resources

• Motivations in using threads• Models for organizing threads• Issues in designing a threads package• Implementing a threads package

Motivations in using Threads• Overheads are lower in creating threads than

processes• Switching threads has lower overhead that

process/task switching• Threads allow parallelism to be combined with

sequential execution with blocking system calls• Resource sharing is easier with threads than

processes as the threads share the same address space

Models for Organizing Threads• Dispatcher-workers model

o Single dispatcher, multiple workers. Dispatcher accepts requests and hands over the work to a free worker. Similar kind of service calls can be parallelized.

• Team modelo All threads are equal. Could be like a collection of specialized threads

that can service several types of services in parallel.• Pipeline model

o Good for situations where one part produces output that is used by another part as consumer. Can be set up as a pipeline where output of one is used by the second, out put of which may be used by another thread in a sequence or pipe line

Issuesin

Designing a Threads Package• Threads creation

o Static or dynamic. Static calls create all the threads required at compile time. While dynamic creation creates threads as needed through a system call. Stack size is a parameter along with scheduling priority and the process that includes the thread . System call returns a thread id

• Threads terminationo Exit call to kill itself or a specific external kill command given the thread id.

• Threads synchronization• Threads scheduling• Signal handling

Threads Synchronization• Shares same address space so there can be problems if multiple threads

try to manipulate the same variable.• Use critical regions that only one thread can enter at a time.• Access is controlled by mutex variable, works as of way of the following

o Threads are blocked and enters a queue waiting on the mutex ORo Return an error code indicating access is not possible. The thread can

decide to continue with something else but needs to acquire the lock to get access

• Condition variable wait and signal can be used to check lock availability and release

Threads Scheduling• Priority assignment

o Priority based assignment; can be non-preemptive or preemptive• Vary quantum size dynamically

o Vary the quantum of the time slice in a round robin scheme dynamically. Vary the quantum inversely with the number of threads present in the system

• Handoff schedulingo One thread relinquishing the CPU designated which thread it should be

given to. A sender, for example, can request that the receiver thread be handed over the processor.

• Affinity schedulingo A thread is scheduled on the last node it ran on. Assuming some of the address

space it used may still be in the cache

Signal Handling• A signal must be handled no matter what• Typically a routine within the process handles it to

ensure that• Signals should not get lost. Exceptions can interfere,

overwrite global variables• Exception handlers for all types of exception should

be present to manage properly

Implementing Threads Package• User level

o A runtime system manages threads, a status information table is also maintained. Each entry has state of thread, registers, priority etc.

o Scheduling via kernel for the process, then the runtime divides the time quantum to the threads in the process

• Kernel levelo No separate runtime required, thread status information table

maintained at kernel level, kernel is able to schedule thread the same way a process is scheduled. A single level scheduling process

User Level vs. Kernel LevelThreads Packages

• User level package can be implemented on top of an OS that does not support threads

• Two level scheduling provides scheduling flexibility• Switching is faster in user level package as the run time rather than the

kernel does it• On user level a thread can be stopped only if the process is stopped as the

process containing the thread only can be stopped by the kernel• Threads should not be allowed to make blocking system calls as it’ll block

the process. Jacket calls can be used