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 Thomas E. Anderson, Brian N. Bershad, Edward D. Lazowska, and Henry M. Levy Presented by Patrick Leyshock Thanks to Reinette Grobler

2. DESIGN QUESTIONS • How do we implement threads? • Design questions: • What’s the relationship between threads, the user, and the kernel? • How many threads can there be? In user space? In kernel space? • Who schedules threads? • When/how are threads scheduled? • How/by whom are threads created? • What happens to threads when they’ve done their work?

3. THREAD MODELS • Kernel-level threads (KLTs) • kernel handles administrative tasks • users access threads through an API • e.g. Windows NT • - User-level threads (ULTs) • user handles administrative tasks • kernel does not know that theads exist • e.g. user-level thread library, such as pthreads

4. KLTs – PROS AND CONS • + good performance in conditions when threads suffer page faults, make blocking system calls, etc. • management overhead under normal circumstances – context changes, thread creation, etc. • potential for improper/incorrect operation

5. ULTs – PROS AND CONS • + administrative costs extremely low, performance high • + scheduling, etc. can be custom-tailored to the application • poor performance under certain conditions (e.g. page faults, when a thread makes a blocking system call, etc.)

6. AUTHORS’ PROPOSAL • - Keep an implementation of threads at the user-level. • Discard the idea of kernel-level threads “supporting” user-level threads. • Introduce a new abstraction for managing the relationship between ULTs and the kernel. The new abstraction allows: • user-level management of threads, when the kernel is not needed • better interactions between the user-level thread scheduler and the kernel

7. SCHEDULER ACTIVATIONS - 1 • Tool for bi-directional communication between the kernel, and the user-level thread library • The kernel: • allocates processors to address spaces • notifies address spaces of events affecting that address space • The user-level thread library • schedules threads • notifies the kernel of the subset of user-level events that can affect processor allocation

8. SCHEDULER ACTIVATIONS - 2

9. SOLVING PROBLEMS, PRESERVING BENEFITS KLTs ULTs + good performance in conditions when threads suffer page faults, make blocking system calls, etc. - management overhead under normal circumstances – context changes, thread creation, etc. - potential for improper/incorrect operation + administration costs extremely low + scheduling, etc. can be custom-tailored to the application - poor performance under certain conditions (e.g. page faults, when a thread makes a blocking system call, etc.)

10. IMPLEMENTATION • Scheduler activations added to Topaz kernel thread management. • Does not schedule – instead performs upcalls • Explicitly allocates processors to address spaces • Modifications to FastThreads user-level thread package • Processes upcalls • Resumes interrupted critical sections. • Passes processor allocation information to Topaz

11. PERFORMANCE • Thread performance without kernel involvement similar to FastThreads before changes • Upcall performance significantly worse than Topaz threads • Application performance • Negligible I/O: As quick as original FastThreads • With I/O: Performs better than either FastThreads or Topaz threads

12. PROBLEMS/COMMENTS • Upcall performance significantly worse than Topaz threads • Untuned implementation? Language differences?? • Other problems? • What if user-level library code is preempted by a scheduler activation? • What happens when the user-level library code blocks? • Repeating page faults • Critical sections

13. PERFORMANCE – 2 – NO I/O

14. PERFORMANCE - 3 – WITH I/O