MODULE-4 RESOURCE & PROCESS

MANAGEMENT
RESOURCE MANAGEMENT IN DS
• Every distributed system consists of a number of resources interconnected by a network. Besides
providing communication facilities, the network facilitates resource sharing by migrating a local
process and executing it at a remote node of the network.
• A process may be migrated because the local node does not have the required resources or the
local node has to be shut down.
• From a user's point of view, the set of available resources in a distributed system acts like a single
virtual system. Hence, when a user submits a process for execution, it becomes the responsibility of
the resource manager of the distributed operating system to control the assignment of resources to
processes and to route the processes to suitable nodes of the system according to these
assignments.
• A Resource can be logical, such as a shared file, or physical, such as a CPU.
RESOURCE MANAGEMENT IN DS(1)
A resource manager schedules the processes in a distributed system to make use of the system
resources in such a manner that resource usage, response time, network congestion, and
scheduling overhead are optimized.

Differing techniques and methodologies for scheduling processes of a distributed system

DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM
1. No A Prior Knowledge about the Process

• A good process scheduling algorithm should operate with absolutely no a

prior knowledge about the processes to be executed. Scheduling algorithms
that operate based on the information about the characteristics and resource
requirements of the processes normally pose an extra burden upon the users
who must specify this information while submitting their processes for execution.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(1)
2.Dynamic In Nature
• It is intended that a good process-scheduling algorithm should be able to take
care of the dynamically changing load (or status) of the various nodes of the
system. That is, process assignment decisions should be based on the current load
of the system and not on some fixed static policy.
• For this, sometimes it is also recommended that the scheduling algorithm should
possess the flexibility to migrate a process more than once because the initial
decision of placing a process on a particular node may have to be changed after
some time to adapt to the new system load.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(2)
3. Quick Decision-Making Capability
A good process-scheduling algorithm must make quick decisions about the assignment
of processes to processors.

4. Balanced System Performance and Scheduling Overhead

Several global scheduling algorithms collect global state information and use this
information in making process assignment decisions. A common intuition is that
greater amounts of information describing global system state allow more intelligent
process assignment decisions to be made that have a positive affect on the system
as a whole.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(3)
Stability

A scheduling algorithm is said to be unstable if it can enter a state in which all the nodes of the
system are spending all of their time migrating processes without accomplishing any useful work
in an attempt to properly schedule the processes for better performance. This form of fruitless
migration of processes is known as processor thrashing.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(4)
Stability

For example, it may happen that nodes n1 and n2 both observe that node n3 is idle and
then both offload a portion of their work to node n3 without being aware of the offloading
decision made by the other. Now if node n3 becomes overloaded due to the processes
received from both nodes n1 and n2' then it may again start transferring its processes to
other nodes. This entire cycle may be repeated again and again, resulting in an unstable
state. This is certainly not desirable for a good scheduling algorithm.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(5)
Scalability
• A scheduling algorithm should be capable of handling small as well as large networks. An algorithm
that makes scheduling decisions by first inquiring the workload from all the nodes and then selecting
the most lightly loaded node as the candidate for receiving the process(es) has poor scalability factor.
Such an algorithm may work fine for small networks but gets crippled when applied to large networks.
• This is because the inquirer receives a very large number of replies almost simultaneously, and the time
required to process the reply messages for making a host selection is normally too long. Moreover, the
N2 (N is the total number of nodes in the system) nature of the algorithm creates heavy network traffic
and quickly consumes network bandwidth. A simple approach to make an algorithm scalable is to
probe only m of N nodes for selecting a host. The value of m can be dynamically adjusted depending
upon the value of N.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(6)
Fault Tolerance

A good scheduling algorithm should not be disabled by the crash of one or more nodes of the
system. At any instance of time, it should continue functioning for nodes that are up at that time.
Moreover, if the nodes are partitioned into two or more groups due to link failures, the algorithm
should be capable of functioning properly for the nodes within a group.
DESIRABLE FEATURES OF A GOOD GLOBAL SCHEDULING ALGORITHM(7)
Fairness or Service

While the average quality of service provided is clearly an important performance index, how
fairly service is allocated is also a common concern. For example, two users simultaneously
initiating equivalent processes expect to receive about the same quality of service.
Several researchers think that global scheduling policies that blindly attempt to balance the
average load on all the nodes of the system are not good from the point of view of fairness of
service.
This is because in any load-balancing scheme, heavily loaded nodes will obtain all the benefits
while lightly loaded nodes will suffer poorer response time than that in a stand-alone
configuration.
RESOURCE MANAGEMENT
• Task assignment approach
• Load balancing approach
• Load sharing approach.
TASK ASSIGNMENT APPROACH

Main assumptions
• Processes have been split into tasks
• Computation requirement of tasks and speed of processors are known.
• Cost of processing tasks on nodes are known.
• Communication cost between every pair of tasks are known.
• Resource requirements and available resources on node are known.
• Reassignment of tasks are not possible.
TASK ASSIGNMENT APPROACH

Basic idea: Finding an optimal assignment to achieve goals such as the

following:
• Minimization of IPC costs
• Quick turnaround time of process
• High degree of parallelism
• Efficient utilization of resources
 Example of Task Assignment Approach:
Let us suppose, there are two nodes namely n1
and n2, and six tasks namely t1, t2, t3, t4, t5,
and t6. The two task assignment parameters
are:
execution cost: xab refers to the cost of
executing a task a on node b.
Inter-task communication cost: cij refers to
inter-task communication cost between tasks i
and j.

Note: The execution of the task (t2) on the node (n2) and the execution of the task (t6) on the node (n1) is
not possible as it can be seen from the above table of Execution costs that resources are not available.
Cost of Execution in Serial Assignment:
= t11 + t21 + t31 + t42 + t52 + t62
= 5 + 2+ 4 + 3 + 2 + 4
= 20 (Refer Execution Cost table)

Cost of Communication in Serial Assignment:

= c14 + c15 + c16 + c24 + c25 + c26 + c34 + c35 + c36
= 0 + 0+ 12 + 12 + 3 + 0 + 0 + 11 + 0
= 38 (Refer Inter-task Communication Cost table)
Hence, Total Cost in Serial Assignment
= 20 + 38
= 58
)

Cost of Execution in Optimal Assignment:

= t11 + t21 + t31 + t41 + t51 + t62
= 5 + 2+ 4 + 6 + 5 + 4
= 26 (Refer Execution Cost table

Cost of Communication in Serial Assignment:

= c16 + c26 + c36 + c46 + c56
= 12 + 0+ 0 + 0 + 0
= 12 (Refer Inter-task Communication Cost table)
Hence, Total Cost in Optimal Assignment
= 26 + 12
= 38
LOAD BALANCING
• Load balancing is an art or method of distributing load units/jobs/tasks
across a network of processors that may be distributed globally.
• The load balancing algorithm attempts to balance the load by transparently
transferring the workload from a heavily loaded node to lightly loaded node,
so that same load is executed by multiple nodes in the system.
• The excess load or remaining unexecuted load from a processor is migrated
to other processors based on the threshold value or load.
LOAD BALANCING
Benefits of Load Balancing
1. It reduces idle time on the jobs.
2. Small jobs are not starved for long period.
3. It makes the best use of available resources.
4. The response time decreases.
5. It has high throughput.
6. It has a low cost but a high profit.
7. It allows extensibility & incremental growth.
8. Load balancing improves node performance and thus system performance.
LOAD ESTIMATION POLICY
In load estimation policy, the basic focus is on the estimation of following
parameters:
1. Total no of processes on the node at the time of load estimation.
2. Resource demand of these processes.
3. Instruction mixes of these processes.
4. Architecture & speed of the node’s processor.
5. Sum of remaining service time of all processes on a node can be a measure
for estimating a node’s workload.
LOAD ESTIMATION POLICY
In some cases the true load could vary widely depending on the remaining service time,
which can be measured in several way:
• Memoryless method assumes that all processes have the same expected remaining service
time, independent of the time used so far
• Past repeats assumes that the remaining service time is equal to the time used so far
• Distribution method states that if the distribution service times is known, the associated
process’s remaining service time is the expected remaining time conditioned by the time
already used.
LOAD ESTIMATION POLICY
• None of the previous methods can be used in modern systems because of periodically
running processes and daemons.
• An acceptable method for use as the load estimation policy in these systems would be to
measure the CPU utilization of the nodes.
• Central Processing Unit utilization is defined as the number of CPU cycles actually executed
per unit of realtime
• It can be measured by setting up a timer to periodically check the CPU state(idle/busy).
PROCESS TRANSFER POLICY
• Most of the algorithms use the threshold policy to decide on whether the node is
lightly- loaded or heavily-loaded.
• Threshold value is a limiting value of the workload of node which can be determined by

1. Static policy: predefined threshold value for each node depending on processing
capability
2. Dynamic policy: threshold value is calculated from average workload and a predefined
constant

• Below threshold value node accepts processes to execute, above threshold value node
tries to transfer processes to a lightly-loaded node
PROCESS TRANSFER POLICY
• Single-threshold policy may lead to unstable algorithm because underloaded
• node could turn to be overloaded right after a process migration.
• To reduce instability double-threshold policy has been proposed which is also
• known as high-low policy.

Overloaded
Overloaded
High mark
Threshold Normal
Low mark
Underloaded
Underloaded

Single-threshold policy Double-threshold policy

PROCESS TRANSFER POLICY
Double threshold policy
• When node is in overloaded region new local processes are sent to run
remotely, requests to accept remote processes are rejected
• When node is in normal region new local processes run locally,
requests to accept remote processes are rejected

• When node is in underloaded region new local processes run locally,

requests to accept remote processes are accepted
STATE INFORMATION EXCHANGE POLICY

Dynamic policies require frequent exchange of state but these information,

extra messages arise two opposite impacts:
• Increasing the number of messages gives more accurate scheduling
decision
• Increasing the number of messages raises the queuing time of messages
State information policies can be the following:
• Periodic broadcast
• Broadcast when state
changes
• On-demand exchange
• Exchange by polling
STATE INFORMATION EXCHANGE POLICY
Periodic broadcast
• Each node broadcasts its state information after the elapse of every T
units of time
• Problem: heavy traffic, fruitless messages, poor scalability since
information exchange is too large for networks having many nodes
Broadcast when state changes
• Avoids fruitless messages by broadcasting the state only when a
process arrives or departures
• Further improvement is to broadcast only when stateswitches to
another region (double-threshold policy)
STATE INFORMATION EXCHANGE POLICY

On-demand exchange
• In this method a node broadcast a State-Information-Request
message when its state switches from normal to either underloaded or
overloaded region.
• On receiving this message other nodes reply with their own
state information to the requesting node Further improvement can be
that only those nodes reply which are useful to the requesting node
Exchange by polling
• To avoid poor scalability (coming from broadcast messages) the
partner node is searched by polling the other nodes one by one, until
poll limit is reached
LOCATION POLICY
Threshold method
• Policy selects a random node, checks whether the node is able to receive the
process, then transfers the process. If node rejects, another node is selected
randomly. This continues until probe limit is reached.

Shortest method
• Some distinct nodes are chosen at random, each is polled to determine its load.
The process is transferred to the node having the minimum value unless its
workload value prohibits to accept the process.

• Simple improvement is to discontinue probing whenever

a node with zero load is encountered.
LOCATION POLICY
Bidding method
• Nodes contain managers (to send processes) and contractors (to receive processes)
• Managers broadcast a request for bid, contractors respond with bids (prices
based on capacity of the contractor node) and manager selects the best offer
• Winning contractor is notified and asked whether it accepts the process for
execution or not
Disadvantages:
• Full autonomy for the nodes regarding scheduling
• Big communication overhead
• Difficult to decide a good pricing policy
LOCATION POLICY
Pairing
• Contrary to the former methods the pairing policy is to reduce the variance of load
only between pairs.
• Each node asks some randomly chosen node to form a pair with it
• If it receives a rejection it randomly selects another node and tries to pair again
• Two nodes that differ greatly in load are temporarily paired with
each other and migration starts.
• The pair is broken as soon as the migration is over.
• A node only tries to find a partner if it has at least two processes
PRIORITY ASSIGNMENT POLICY
Selfish : Local processes are given higher priority than remote processes. Worst
response time performance of the three policies.
Altruistic : Remote processes are given higher priority than local processes. Best
response time performance of the three policies.
Intermediate : When the number of local processes is greater or equal to the
number of remote processes, local processes are given higher priority than remote
processes. Otherwise, remote processes are given higher priority than local processes.
MIGRATION LIMITING POLICY
This policy determines the total number of times a process can
migrate
1. Uncontrolled: A remote process arriving at a node is treated just as a
process originating at a node, so a process may be migrated any
number of times.
2. Controlled: Avoids the instability of the uncontrolled policy.
• Use a migration count parameter to fix a limit on the number of
time a process can migrate.
• Irrevocable migration policy: migration count is fixed to 1
• For long execution processes migration count must be greater than
1 to adapt for dynamically changing states
LOAD-SHARING APPROACH
Drawbacks of Load-balancing approach
• Load balancing technique with attempting equalizing the workload on all the nodes is
not an appropriate object since big overhead is generated by gathering exact state
information.
• Load balancing is not achievable since number of processes in always fluctuating node
is and temporal unbalance among the nodes exists every moment
Basic ideas for Load-sharing approach
• It is not necessary to balance the load on all nodes, other nodes have more than two
processes running, which is both necessary & sufficient to keep nodes from becoming
idle.
• Load-sharing is much simpler than load-balancing since it only attempts to ensure that no
node is idle when heavily node exists.
• Priority assignment policy and migration limiting policy are the same as
that for the load-balancing algorithms.
LOAD ESTIMATION POLICIES
• Since load-sharing algorithms simply attempt to avoid idle nodes, it is
sufficient to know whether a node is busy or idle
• Thus these algorithms normally employ the simplest load estimation policy
of counting the total number of processes

• In modern systems where permanent existence of several processes on an idle

node is possible, algorithms measure CPU utilization to estimate the load of
a node
PROCESS TRANSFER POLICIES
• Algorithms normally use all-or-nothing strategy
• This strategy uses the threshold value of all the nodes fixed to 1
• Nodes become receiver node when it has no process, and become sender node
when it has more than 1 process

• To avoid processing power on nodes having zero process load-sharing

algorithms use a threshold value of 2 instead of 1
• When CPU utilization is used as the load estimation policy, the double-
threshold policy should be used as the process transfer policy
LOCATION POLICIES
Location policy decides whether the sender node or the receiver node of the
process takes the initiative to search for suitable node in the system, and this
policy can be the following:
Sender-initiated location policy
• Sender node decides where to send the process
• Heavily loaded nodes search for lightly loaded nodes
Receiver-initiated location policy
• Receiver node decides from where to get the process
• Lightly loaded nodes search for heavily loaded nodes
LOCATION POLICIES
Sender-initiated location policy
• Node becomes overloaded, it either broadcasts or randomly probes
the other nodes one by one to find a node that is able to receive
remote processes
• When broadcasting, suitable node is known as soon as reply arrives
Receiver-initiated location policy
• Nodes becomes underloaded, it either broadcast or randomly probes
the other nodes one by one to indicate its willingness to receive remote
processes
Receiver-initiated policy require preemptive process migration facility
since scheduling decisions are usually made at process departure epochs
LOCATION POLICIES
Experiences with location policies
Both policies gives substantial performance advantages
over the situation in which no load-sharing is attempted
• Sender-initiated policy is preferable at light to moderate system
loads
• Receiver-initiated policy is preferable at high system loads
Sender-initiated policy provide better performance for the case when
process transfer cost significantly more at receiver-initiated than at
sender-initiated policy due to the preemptive transfer of processes
STATE INFORMATION EXCHANGE POLICIES
• In load-sharing algorithms it is not necessary for the nodes to periodically exchange
state information, but needs to know the state of other nodes when it is either
underloaded or overloaded.
1. Broadcast when state changes
• In sender-initiated/receiver-initiated location policy a node broadcasts State
Information Request when it becomes overloaded/underloaded
• It is called broadcast-when-idle policy when receiver-initiated policy is used
with fixed threshold value of 1.
2. Poll when state changes
• In large networks polling mechanism is used
• Polling mechanism randomly asks different nodes for state information
until find an appropriate one or probe limit is reached
• It is called poll-when-idle policy when receiver-initiated policy is
used with fixed threshold value of 1.