Cs 704 d aos-resource&processmanagement


Published on

Advanced OS, resource management, process management

Published in: Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Cs 704 d aos-resource&processmanagement

  1. 1. CS 704DAdvanced Operating System( Resource & Process Management)<br />Debasis Das<br />
  2. 2. Resource and Process Management<br />IT 703D Debasis Das<br />
  3. 3.
  4. 4. Resource management Approaches<br /><ul><li>Task Assignment approach
  5. 5. Tasks are assigned to suitable nodes
  6. 6. Load balancing approach
  7. 7. Processes are distributed so as to balance load on nodes
  8. 8. Load sharing approach
  9. 9. Processes are distributed equitably, so that no node is idle while there is queue for some node</li></li></ul><li>Features ofof Good Global Scheduling<br /><ul><li>No a-priori knowledge about processes
  10. 10. Dynamic in nature
  11. 11. Quick decision making capability
  12. 12. Balanced system performance and scheduling overhead
  13. 13. Stability
  14. 14. Scalability
  15. 15. Fault tolerance
  16. 16. Fairness of service</li></li></ul><li>Task assignment Approach<br /><ul><li>Assumptions
  17. 17. Process is already broken into tasks
  18. 18. Amount of computation required by a task and speed of processing at nodes are known
  19. 19. Cost of processing at each node is known
  20. 20. IPC costs between every pair of tasks are known
  21. 21. Resource requirements of tasks, availability at each node and precedence of tasks are known
  22. 22. Reassignment of tasks generally not possible</li></li></ul><li>Task assignment ApproachGoals<br /><ul><li>Minimization of IPC costs
  23. 23. Quick turn around for a process
  24. 24. High degree of parallelism
  25. 25. Efficient utilization of system resources</li></li></ul><li>Load Balancing Approach<br /><ul><li>Goal: Maximum throughput
  26. 26. Algorithms available
  27. 27. Static vs. dynamic
  28. 28. Average known performance taken into consideration rather than instantaneous figures
  29. 29. Deterministic vs. probabilistic
  30. 30. A static approach. Processor assignment to a node is fixed.
  31. 31. Centralized vs. distributed
  32. 32. A dynamic method. A centralized server may decide assignments. K servers will make assignments in a decentralized approach
  33. 33. Cooperative vs. non cooperative
  34. 34. 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</li></li></ul><li>Issues in Designing Load Balancing Algorithms<br /><ul><li>Load estimation policy
  35. 35. How the load on a node is estimated
  36. 36. Process transfer policy
  37. 37. Basis of executing a process locally or at a remote node
  38. 38. State information exchange policy
  39. 39. How state information should be exchanged
  40. 40. Priority assignment policy
  41. 41. Priority of local and remote processes at a node
  42. 42. Migration limiting policy
  43. 43. Total number of times a process may be migrated from one another node</li></li></ul><li>Load Estimation policies<br /><ul><li>Load depends on parameters as follows
  44. 44. No. of processes at the node
  45. 45. Resource demand of these active processes
  46. 46. Instruction mixes of these processes
  47. 47. Architecture and speed of the node’s processor</li></li></ul><li>Process Transfer Policies<br /><ul><li>Static
  48. 48. Predetermined threshold is considered depending on the processing capability
  49. 49. Dynamic
  50. 50. Threshold is calculated as a product of the average workload of all nodes. State information is exchanged to determine the threshold at any time
  51. 51. One may use a single threshold policy or the dual threshold policy</li></li></ul><li>Location Policies<br /><ul><li>Once transfer policy is decided where to locate a process is decided by one of the following methods
  52. 52. Threshold
  53. 53. Pick a node at random, check a threshold and then assign if under-loaded
  54. 54. Shortest
  55. 55. Pick p nodes at random, assign to the node with lightest node
  56. 56. Bidding
  57. 57. Each node has a manager and a contractor role. A node that needs service broadcasts need. Contractors bid. Winning bidder gets the process
  58. 58. Pairing
  59. 59. Create pairs between two nodes that do balancing between them</li></li></ul><li>Static Information Exchange Policies<br /><ul><li>Periodic broadcasts
  60. 60. Network traffic increases, not scalable, useless information(no change) many a times
  61. 61. Broadcast when state changes
  62. 62. Additionally, one can broadcast only when overloaded or under-loaded
  63. 63. On-demand exchange
  64. 64. Only when under-loaded or overloaded
  65. 65. Exchange by polling
  66. 66. Poll random nodes. Stop when a partner is found or polling limit is reached</li></li></ul><li>Priority Assignment policies<br /><ul><li>Priority assignment rules required for local as well as remote processes
  67. 67. Rules used could be
  68. 68. Selfish
  69. 69. Local processes get higher priority
  70. 70. Altruistic
  71. 71. Remote processes get higher priority
  72. 72. Intermediate
  73. 73. Depending on no of local processes & remote processes. Local processes get priority if more no. of local processes & vice versa</li></li></ul><li>Migration limiting policies<br /><ul><li>Uncontrolled
  74. 74. Any process arriving at a node is welcome. Can cause instability
  75. 75. Controlled
  76. 76. 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</li></li></ul><li>Load-sharing approach<br /><ul><li>Issues in load-sharing algorithms
  77. 77. Load estimation policies
  78. 78. Process transfer policies
  79. 79. Location policies
  80. 80. Sender-initiated location policies
  81. 81. Receiver initiated location policy
  82. 82. State information Exchange policies
  83. 83. Broadcast when state changes
  84. 84. Poll when state changes</li></li></ul><li>Load Estimation Policies<br /><ul><li>All one needs to know is if a node is idle
  85. 85. There may be several processes running on current distributed systems
  86. 86. CPU utilization may be a good estimator</li></li></ul><li>Location Policies<br /><ul><li>Sender initiated policies
  87. 87. A overloaded node may broadcast for a lightly loaded node or poll nodes
  88. 88. Receiver initiated policies
  89. 89. 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.</li></li></ul><li>State Information Exchange Policies<br /><ul><li>Broadcast when state changes
  90. 90. State information request message is sent out only when a node goes belo9w/above threshold
  91. 91. Poll when state changes
  92. 92. Poll only when the state changes.
  93. 93. In either case, location policy decides if the overloaded node or the under-loaded node initiates the action</li></li></ul><li>
  94. 94. Process Management<br /><ul><li>Manage processes such that all processing resources are utilized in the best possible manner.
  95. 95. Important concepts in this regard,
  96. 96. Processor allocation: which process goes to which processor
  97. 97. Process migration: should the process be migrated to some other processor
  98. 98. Threads: fine grained parallelism to better utilize resources</li></li></ul><li>Process Migration<br /><ul><li>Issues
  99. 99. Selection of a process to be migrated
  100. 100. Selection of destination node
  101. 101. Actual transfer of the process
  102. 102. Actual time taken when the process is being transferred is “freezing time”, the process is stopped
  103. 103. Preemptive and non-preemptive transfers
  104. 104. Process migrated before it has started is non-preemptive
  105. 105. Process migrated when it is in execution is preemptive, will need the whole execution state to be transferred</li></li></ul><li>Process MigrationDesirable Features<br /><ul><li>Transparency
  106. 106. 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
  107. 107. System call and IPC level: system calls & IPC need to be system/location independent . This then can support pre-emptive migration
  108. 108. Minimal Interference : minimal freezing time
  109. 109. Minimal residual dependencies: once a process migrates, there should not be any dependency left in the source system
  110. 110. Efficiency: time & cost to be minimal
  111. 111. Robustness: other than failure of the current execution node, nothing else should matter
  112. 112. Communication between co-processes of a job: if co-processes are distributed they should be able to communicate freely</li></li></ul><li>Process MigrationProcess Migration Mechanisms<br /><ul><li>Migration activities
  113. 113. Freezing on source node, restarting on destination node
  114. 114. Transferring of process address space
  115. 115. Forwarding messages meant for the process migrated
  116. 116. Handling communication between co-operating process</li></li></ul><li>Freezing & Restart of Processes<br /><ul><li>Issues
  117. 117. Immediate & delayed blocking of processes
  118. 118. Fast & slow I/O operations
  119. 119. Reinstating the process on destination node
  120. 120. Address space transfer
  121. 121. Total freezing
  122. 122. Pre-transferring
  123. 123. Transfer on reference</li></li></ul><li>Blocking of Processes<br /><ul><li>In preemptive migration, a snapshot of the process is to be taken. This is to be restored at destination
  124. 124. Blocking at source can take place only when
  125. 125. Process is not executing a system call, block immediately
  126. 126. Process is executing a system call and sleeping at a interruptible priority level, block immediately.
  127. 127. 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.</li></li></ul><li>Fast & Slow I/O Operations<br /><ul><li>Freezing occurs after fast I/O such as disk I/O are completed.
  128. 128. Waiting for slow I/O such as terminal I/O may not be feasible.
  129. 129. Some means of continuing slow I/O after migration will be required
  130. 130. Information about open files
  131. 131. A link to the open file is created
  132. 132. A complete path name from the new node is created</li></li></ul><li>Re-instating on Destination Node<br /><ul><li>A new empty process state is created on destination node
  133. 133. In some implementations this may have a different process id for a while
  134. 134. After the migration happens completely the id may be changed to the original id and the original process deleted
  135. 135. 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.</li></li></ul><li>Address Space Transfer Mechanisms<br /><ul><li>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
  136. 136. Process’s address space that includes code, data and stack
  137. 137. 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</li></li></ul><li>Transfer Mechanisms<br /><ul><li>Total freezing
  138. 138. Source process is frozen until not only the process but also address space transfer is complete, takes a longer freeze time
  139. 139. Pre-transferring
  140. 140. Address space transfer is completed before the source process is frozen and migration completed
  141. 141. Transfer on reference
  142. 142. Address space transfer takes place only when the restarted, migrated process makes reference to anywhere in the address space</li></li></ul><li>Message Forwarding Mechanisms<br /><ul><li>Kinds of messages
  143. 143. Messages that arrive after source process is frozen but the destination process has not started
  144. 144. Message at source node after the process has started at destination node
  145. 145. Messages to the migrant process after the execution at destination has started
  146. 146. Resending the message mechanism
  147. 147. Drop the message, let the senders retransmit messages again after locating the destination process
  148. 148. Origin site mechanism
  149. 149. Each node receiving message for processes on it, keep track of the migration and forward messages
  150. 150. Link traversal mechanism
  151. 151. 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.
  152. 152. Link update mechanism
  153. 153. 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. </li></li></ul><li>Handling Co-processes<br /><ul><li>Disallowing separation of co-processes
  154. 154. Disallow migration of a processes whose children are yet to complete
  155. 155. When a process does migrate, ensure all the children go with it
  156. 156. Home node or origin site concept
  157. 157. A home node is defined, all communications work though this node. So that when separated they still can communicate. Network traffic increases though</li></li></ul><li>Process MigrationinHeterogeneous Systems<br /><ul><li>Main issue is different data representation on machines
  158. 158. An external data representation is created
  159. 159. Floating point numbers are, typically, need the most consideration in creating the representation. Following need to be considered very closely
  160. 160. Exponent handling
  161. 161. Mantissa handling
  162. 162. Signed infinity and signed zero representations</li></li></ul><li>Process MigrationAdvantages<br /><ul><li>Reducing average response times of processes
  163. 163. Speeding up individual jobs
  164. 164. Gaining higher throughput
  165. 165. Utilizing resources effectively
  166. 166. Reducing network traffic
  167. 167. Improving system reliability
  168. 168. Improving system security</li></li></ul><li>
  169. 169. Threads<br /><ul><li>General
  170. 170. Share an address space & open files, global variable, child processes, semaphores, signals, accounting information and other OS resources
  171. 171. Motivations in using threads
  172. 172. Models for organizing threads
  173. 173. Issues in designing a threads package
  174. 174. Implementing a threads package</li></li></ul><li>Motivations in using Threads<br /><ul><li>Overheads are lower in creating threads than processes
  175. 175. Switching threads has lower overhead that process/task switching
  176. 176. Threads allow parallelism to be combined with sequential execution with blocking system calls
  177. 177. Resource sharing is easier with threads than processes as the threads share the same address space</li></li></ul><li>Models for Organizing Threads<br /><ul><li>Dispatcher-workers model
  178. 178. Single dispatcher, multiple workers. Dispatcher accepts requests and hands over the work to a free worker. Similar kind of service calls can be parallelized.
  179. 179. Team model
  180. 180. All threads are equal. Could be like a collection of specialized threads that can service several types of services in parallel.
  181. 181. Pipeline model
  182. 182. 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</li></li></ul><li>IssuesinDesigning a Threads Package<br /><ul><li>Threads creation
  183. 183. 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
  184. 184. Threads termination
  185. 185. Exit call to kill itself or a specific external kill command given the thread id.
  186. 186. Threads synchronization
  187. 187. Threads scheduling
  188. 188. Signal handling</li></li></ul><li>Threads Synchronization<br /><ul><li>Shares same address space so there can be problems if multiple threads try to manipulate the same variable.
  189. 189. Use critical regions that only one thread can enter at a time.
  190. 190. Access is controlled by mutex variable, works as of way of the following
  191. 191. Threads are blocked and enters a queue waiting on the mutex OR
  192. 192. 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
  193. 193. Condition variable wait and signal can be used to check lock availability and release</li></li></ul><li>Threads Scheduling<br /><ul><li>Priority assignment
  194. 194. Priority based assignment; can be non-preemptive or preemptive
  195. 195. Vary quantum size dynamically
  196. 196. 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
  197. 197. Handoff scheduling
  198. 198. 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.
  199. 199. Affinity scheduling
  200. 200. 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</li></li></ul><li>Signal Handling<br /><ul><li>A signal must be handled no matter what
  201. 201. Typically a routine within the process handles it to ensure that
  202. 202. Signals should not get lost. Exceptions can interfere, overwrite global variables
  203. 203. Exception handlers for all types of exception should be present to manage properly</li></li></ul><li>Implementing Threads Package<br /><ul><li>User level
  204. 204. A runtime system manages threads, a status information table is also maintained. Each entry has state of thread, registers, priority etc.
  205. 205. Scheduling via kernel for the process, then the runtime divides the time quantum to the threads in the process
  206. 206. Kernel level
  207. 207. 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</li></li></ul><li>User Level vs. Kernel LevelThreads Packages<br /><ul><li>User level package can be implemented on top of an OS that does not support threads
  208. 208. Two level scheduling provides scheduling flexibility
  209. 209. Switching is faster in user level package as the run time rather than the kernel does it
  210. 210. 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
  211. 211. Threads should not be allowed to make blocking system calls as it’ll block the process. Jacket calls can be used</li>