1 / 20

By: Skyler Dodge

What is the Dispatcher?. General Computing Terminology. Module that gives control of the CPU to the process selected by the short-term schedulerInvoked during every process switchStops one process and starts anotherInvolves:Context switchingSwitching to user modeJumping to the proper location in the user program to restart that program.

shika
Télécharger la présentation

By: Skyler Dodge

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. z/OS Dispatcher By: Skyler Dodge

    3. General Computing Terminology Module that gives control of the CPU to the process selected by the short-term scheduler Invoked during every process switch Stops one process and starts another Involves: Context switching Switching to user mode Jumping to the proper location in the user program to restart that program

    4. z/OS Terminology Scheduler for the Task Control Block (TCB) and Service Request Block (SRB) Dispatchers duties: Selects SRB or TCB Loads state information Controls the time the unit of work runs for Saves state information Allows for multitasking within a system

    6. Overview 1974 Original MVS implementation: MVS/370 Spinlocks 1980 MVS/XA True Ready Queue 1988 MVS/ESA Reduced Preemption 1995 OS/390 Dispatcher rewrite 2008 HiperDispatch: a more intelligent Dispatcher

    7. Problem in Original MVS Only two CPUs in a system Limited resources and limited access Spinlocks As one TCB or SRB was accessing resources, these would put the system in a wait mode Dispatcher would loop and have to wait for the lock to be opened System was too disrupted for access to be given, and therefore increased overhead

    8. Solution Intersects implemented Global and local Dispatcher would obtain an intersect, which would give access to the queue containing the work elements Instead of locking the whole queue, intersects would only lock the individual work element currently being accessed by the dispatcher and its specific resources

    9. Problem in MVS/370 Multiple queues to search for work Global SRBs, local SRBs, local TCBs Swapped in the address space according to priority order Increase in number of work units meant increased overhead of the dispatcher to search the numerous queues Fairness issues Biased priority by the order of the queues

    10. Solution True Ready Queue Contained the Address Space Control Block (ASCB) Stored the address spaces of the local SRBs and TCBs Dispatcher would do the following: Cycle through the ASCB Find work ready to be executed Swap it in Give it higher immediate priority Provided some fairness due to its queue rotation Reduced dispatcher search overhead Implemented in MVS/XA 2.1.7

    12. Preemption Problem Preemption Non-preemptive dispatcher Voluntary or co-operative Unable to force processes off of the CPU Causes starvation of processes if all incoming work is of higher priority Preemptive dispatcher Forcibly removes processes from a CPU when that CPU needs to be allocated to another process Prevents important SRBs from executing while a previous process is running

    13. Solution Reduced preemption, or partial preemption Achieved through timeslicing Cycles through executing work and gives each work element a certain time to run before stopping it and moving to the next waiting work Became adjustable to account for highest priority SRBs Constant checking by the System Resource Manager (SRM) Carried out by the dispatcher Reduced overhead Increased amount of work units being executed Introduced in MVS/ESA

    14. Another Problem Dispatcher is running on multiple CPUs Pointer to the first ready TCB may not be accurate Dispatcher must spend time searching the true ready queue in priority order Global SRBs Local SRBs Local TCBs Causes additional overhead

    15. Solution Only one queue System Work Unit Queue (SWUQ) Contains only ready units of work Work Element Block (WEB) Added by priority Global SRBs, local SRBs, and local TCBs Dispatcher rotates through rather than searching Provides fairness due to queue rotation Reduces the need for timeslicing Added in MVS/ESA 5.1.0

    17. Problem with Advancing Technology Dispatcher needs to be able to: Access memory easily Transfer CPU control quickly More CPUs causes increased overhead and memory access issues Dispatcher had greater search time

    18. Solution HiperDispatch Works with the Workload Manager (WLM) to determine what actions to take WLM finds most suitable CPU for current task to be executed CPU is most suitable if it contains relevant data on the current task being held by the dispatcher Relevant data increases speed of completion HiperDispatch sends it to that CPU If CPU is busy, HiperDispatch will hold the task for that particular CPU

    19. Additional Enhancements Specialty CPUs z Application Assist Processor (zAAP) Java and XML workloads z Integrated Information Processor (zIIP) DB2 workloads Needs Help dispatcher Sends specific types of work to specific CPU Only sends work dedicated to them to other CPUs if they are unable to keep up with their own workload

    20. Future of the z/OS Dispatcher Dispatcher will continue to improve Must increase performance due to: Constantly improving technology Expanding memory Increased workloads as more tasks are able to run Must become more efficient HiperDispatch does a lot, but it could be better Still waiting to give a task to a CPU with relevant data when there shouldnt even be a need to wait Must utilize all resources and work with the SRM and WLM to effectively multitask

    21. Resources/Acknowledgements Robert Rogers of IBM Angelo Corridori, Director of Large Systems Education at Marist College z/OS Internals: The Dispatcher by Greg Dyck from IBM Share Session 2860 in March 2006 Dispatcher Restructure in the MVS/ESA 5.1.0 Technical Presentation Guide by IBM MVS/ESA Full Vs. Reduced/Partial Preemption by Steve Lambourne of Hitachi Data Systems Corporation Planning Considerations for HiperDispatch Mode by Steve Grabaritis and Bernie Pierce of IBM z/OS Dispatcher Enhancements by Walt Caprice from IBM Share Session 2514 in 2006

More Related