Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism
Download as PPT, PDF5 likes3,995 views
The document discusses 'scheduler activations,' a hybrid threading model that combines the efficiency of user-level threads with the non-blocking nature of kernel threads, enabling better user-level management of parallelism. It outlines the benefits and drawbacks of user-level and kernel-level threading strategies, and details how scheduler activations utilize upcalls to notify user-level thread systems of kernel events. The paper concludes with implications for processor allocation and thread scheduling, emphasizing flexibility for application-specific concurrency models.
Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism
- 1. SCHEDULER ACTIVATIONS Effective Kernel Support for the User-Level Management of Parallelism Kasun Gajasinghe Nisansa de Silva University of Moratuwa Based on the paper “Scheduler Activations - Effective Kernel Support for the User-Level Management of Parallelism” by Thomas E. Anderson et.al.
- 2. Scheduler Activations Introduction to Threads User-Level and Kernel-Level Threads Implementation Pros and Cons Effective Kernel Support for User-Level Management of Parallelism Scheduler Activations Design Implementation Performance Conclusion
- 3. What is a Thread? Smallest unit of processing that can be scheduled by the operating system Similar to a process Separate “thread of execution” Each thread has a separate stack, program counter, and run state
- 4. Why Threads? Perform operations in parallel on the same data Avoid complex explicit scheduling by applications Often more efficient than separate processes Remain responsive for user inputs
- 5. Implementing Threads Three basic strategies User-level: possible on most operating systems, even ancient ones Kernel-level: looks almost like a process (i.e., Linux, Solaris) Scheduler activations (Digital Tru Unix 64, NetBSD, some Mach)
- 7. Thread System - User Level Thread library’s code + data structures in user space Invocation of library function = local function call. Not system call Pros - Good performance Fast thread context switching Better Scaling Highly flexible Custom scheduling algorithms Cons - Poor concurrency support blocking system calls starve sibling threads
- 8. Thread System - System Level Thread library’s code + data structures in kernel space Invocation of library function = system call Pros - Good concurrency support Blocking system calls do not starve sibling threads Cons - Poor performance Operations involve system calls Full context switch to perform thread switches Less Flexible Generic scheduling Algorithm
- 9. User Threads Excellent performance No system calls to perform thread operations More flexible =>Can use domain specific scheduling algorithm (‘customized’ thread library) Blocking system calls such as I/O problematic; Starvation of sibling threads Kernel Threads Bad performance System calls needed to perform thread operations Generic scheduling algorithm( scheduled by kernel) Good integration with system services – blocking calls do not prevent other user threads from being scheduled. Less likelihood of starvation
- 10. Fig. Thread Operation Latencies (micro seconds) Topaz - A highly tuned kernel. FastThreads - A user-level thread library Ultrix - BSD family unix-like OS
- 12. Scheduler Activations Get the best of both worlds — The efficiency and flexibility of user-level threads The non-blocking ability of kernel threads (Poor integration with system services) Relies on upcalls The term “scheduler activation” was selected because each vectored event causes the user-level thread system to reconsider its scheduling decision of which threads to run on which processors.
- 13. Scheduler Activations What’s an Upcall? Normally, user programs call functions in the kernel. Which call as system calls Sometimes, though, the kernel calls a user-level process to report an event Sometimes considered unclean — violates usual layering
- 14. Scheduler Activations Thread creation and scheduling is done at user level When a system call from a thread blocks, the kernel does an upcall to the thread manager The thread manager marks that thread as blocked, and starts running another thread When a kernel interrupt occurs that’s relevant to the thread, another upcall is done to unblock it
- 16. Scheduler Activations It serves as a vessel, or execution context, for running user-level threads, in exactly the same way that a kernel thread does. It notifies the user-level thread system of a kernel event. It provides space in the kernel for saving the processor context of the activation’s current user-level thread, when the thread is stopped by the kernel (e.g., because the thread blocks in the kernel on I/0 or the kernel preempts its processor).
- 17. Scheduler Activations Two execution stacks One mapped into the kernel one mapped into the application address space. Kernel Application Address space
- 18. Scheduler Activations kernel stack is used whenever the user-level thread running in the scheduler activation’s context executes in the kernel (e.g. system call) The kernel also maintains a control block for each activation (akin to a thread control block) to record the state of the scheduler activation when its thread blocks in the kernel or is preempted. Kernel Application Address space
- 19. Scheduler Activations The user-level thread scheduler runs on the activation’s user-level stack and maintains a record of which user-level thread is running in which scheduler activation. Each user-level thread is allocated its own stack when it starts running Kernel Application Address space
- 20. Scheduler Activations - Programs Kernel Application 1 Address space
- 21. Scheduler Activations - Programs Kernel Application 1 Address space
- 22. Scheduler Activations - Upcalls Kernel Application 1 Address space
- 23. Scheduler Activations – thread stopping The crucial distinction between scheduler activations and kernel threads is that once an activation’s user-level thread is stopped by the kernel, the thread is never directly resumed by the kernel.
- 24. Scheduler Activations – thread stopping A new scheduler activation is created to notify the user-level thread system that the thread has been stopped. The user-level thread system removes the state of the thread from the old activation, Tells the kernel that the old activation can be re-used (Explained later) Decides which thread to run on the processor.
- 25. Scheduler Activations – thread stopping The kernel is able to maintain the invariant that there are always exactly as many running scheduler activations (vessels for running user-level threads) as there are processors assigned to the address space.
- 26. Scheduler Activations -Blocking Kernel Application 1 Address space
- 27. Scheduler Activations -Blocking Kernel Application 1 Address space
- 28. Scheduler Activations -Blocking Kernel Application 1 Address space
- 29. Scheduler Activations -Blocking Kernel Application 1 Address space
- 30. Scheduler Activations -Blocking Kernel Application 1 Address space
- 31. Scheduler Activations -Blocking Kernel Application 1 Address space P
- 32. Scheduler Activations -Multiprogramming Application 2 Address space Kernel Application 1 Address space
- 33. Scheduler Activations -Multiprogramming Application 2 Address space Kernel Application 1 Address space P
- 34. Scheduler Activations - Additional if threads have priorities, and there exists running thread with a lower priority than both the unblocked and the preempted thread. Application concurrency model
- 35. Scheduler Activations – Upcall Points
- 36. Scheduler Activations – Address space to Kernel
- 37. Scheduler Activations - Enhancements The processor allocator can favour address spaces that use fewer processors and penalize those that use more. If overall the system has fewer threads than processors, the idle processors should be left in the address spaces most likely to create work in the near future.
- 38. Scheduler Activations – Critical sections A user-level thread could be executing in a critical section at the instant when it is blocked or preempted. Poor performance Deadlock Use “Recovery” instead of “Prevention”
- 39. Scheduler Activations –Critical section Kernel Application 1 Address space P User level context switch!
- 40. Implementation Topaz kernel thread management system Where Topaz formerly blocked, resumed, or preempted a thread, it now performs upcalls to allow the user level to take these actions Do explicit allocation of processors to address spaces Fast threads Process upcalls Resume interrupted critical sections Provide Topaz with needed infomation
- 41. Implementation Topaz kernel thread management system Add 1200 lines (on 4000) Mostly processor allocation policy Fast threads Few hundred lines NB: design is “neutral” on the choice of policies for allocating processors to address spaces and for scheduling threads onto processors.
- 42. Implementation– Processor Allocation Policy Processors are divided evenly among address spaces if some address spaces do not need all of the processors in their share, those processors are divided evenly among the remainder. processors are time-sliced only if the number of available processors is not an integer multiple of the number of address spaces. The kernel processor allocator only needs to know whether each address space could use more processors or has some processors that are idle.
- 43. Implementation– Thread Scheduling Policy kernel has no knowledge of an application’s concurrency model or scheduling policy, or of the data structures used to manage parallelism at the user level. Each application is completely free to choose these as appropriate; they can be tuned to fit the application’s needs.
- 44. Performance Enhancements– Critical sections Have a duplicate code section of the critical section At the end of the copy (Only!) put code to yield the processor back to the resumer.
- 45. Performance Enhancements– Critical sections Normal execution uses the original code. When a preemption occurs, the kernel starts a new scheduler activation to notify the user-level thread system This activation checks the preempted thread’s program counter to see if it was in one of these critical sections If so, continue the thread at the corresponding place in the copy of the critical section. The copy relinquishes control back to the original upcall at the end of the critical section.
- 46. Performance Enhancements– UPCalls Logically, a new scheduler activation is created for each upcall. Creating a new scheduler activation is not free, however, because it requires data structures to be allocated and initialized. Instead, discarded scheduler activations can be cached for eventual re-use. (Remember? )
- 47. Performance Enhancements– Debugging Not very significant to note The point is that you have to use a debugger which have as little effect as possible on the sequence of instructions being debugged.
- 48. Performance Thread performance - without kernel involvement quite similar to FastThreads before the changes. Upcall performance - significantly worse than Topaz threads. Untuned implementation. Topaz in assembler, this system in Modula-2+. Application performance - Negligible I/O: As quick as original FastThreads. With I/O: Performs better than either FastThreads or Topaz threads.
- 49. Performance
- 50. Performance
- 51. Performance
- 52. Summary Processor allocation (the allocation of processors to address spaces) is done by the kernel. Thread scheduling (the assignment of an address space’ threads to its processors) is done by each address space. The kernel notifies the address space thread scheduler of every event affecting the address space. The address space notifies the kernel of the subset of user-level events that can affect processor allocation decisions.
- 53. THANK YOU!
Editor's Notes
- #20: This way, when a thread blocks on a user-level lock or condition variable, the thread scheduler can resume running without kernel intervention.
- #34: Inform that 2 threads have stopped!
- #35: an additional preemption may have to take place beyond the ones described above. For inst ante, on an I/0 completion, some processor could be running a thread with a lower priority than both the unblocked and the preempted thread. In that case, the user-level thread system can ask the kernel to interrupt the thread running on that processor and start a scheduler activation once the thread has been stopped. The user level can know to do this because it knows exactly which thread is running on each of its processors. the kernel’s interaction with the application is entirely in terms of scheduler activations. The application is free to build any other concurrency model on top of scheduler activations; the kernel’s behavior is exactly the same in every case. In particular, the kernel needs no knowledge of the data structures used to represent parallelism at the user level.
- #37: More runnable threads than processors More processors than runnable threads If an applicatlon has notified the kernel that it has idle processors, and the kernel has not taken them away, then there must be no other work in the system, and the kernel need not be notified of changes in parallelism, up to the point where the application has more work than processors. These notifications are only hints: if the kernel gives an address space a processor that is no longer needed by the time it gets there, the address space simply returns the processor to the kernel with the updated information. Of course, the user-level thread system must serialize its notifications to the kernel, since ordering matters.
- #38: This encourages address spaces to give up processors when they are needed elsewhere, since the priorities imply that it is likely that the processors will be returned when they are needed. This avoids the overhead of processor re-allocation when the work is created.
- #39: because other threads continue to test an application-level spin-lock held by the preempted thread the preempted thread could be holding a lock on the user-level thread ready list; if so, deadlock would occur if the upcall attempted to place the preempted thread onto the ready list