1. Scheduler Activations On BSD: Sharing Thread Management Between Kernel and Application Christopher Small and Margo Seltzer Harvard University Presenter: Bhupesh Kothari

2. Outline Scheduler Activation Model Implementation Performance Analysis Analytic Model Conclusions

3. Introduction Thread Models –kernel level threads –user level threads Scheduler Activations –proposed by Anderson T.

4. Processes heavy weight do not share resources communication and switching is expensive applications have no control over process scheduling

5. Threads lighter weight abstraction multiple threads share resources and address space communication is accomplished through shared data

6. Kernel Level Threads processes that share code and data space switching between them is slow application has no control over scheduling suffer from the frequent user-kernel domain crossings and fixed kernel scheduling priorities

7. User Level Threads implemented at application level switching between them is fast user level controls thread scheduling not integrated with the kernel

8. Scheduler Activations thread management between the kernel and the application application creates virtual processors application creates and schedules threads application assigns threads to virtual processors

9. Implementation both kernel and user level support kernel-level support implemented in BSD/386 version 1.0 user-level package:Myth

10. Kernel-Library Interface sfork: creates a child process sigsuspend: kernel puts the virtual processor to sleep until signal is received blocked: a thread blocks in the kernel ready: a thread is ready to run tsleep: is a process that is about to block is virtual processor?

11. Library-Application Interface It includes calls to –fork a child thread –join a child thread –yield the virtual processor to another thread –create and manipulate user level locks level of parallelism: mp User level scheduler selects waiting threads round-robin

12. Library-Application Interface th_init:initialize the thread package and creates mp-1 virtual processors th_fork(func,arg):forks a new child thread th_yield:yield the virtual processor to another thread th_join:wait for the termination of specified thread and accept its return value supports synchronization primitives:locking

13. System Call and Library Support only support for thread context switching is not sufficient to build multithreaded appl. some system system calls cannot be fixed. applications must be written to work around these problems or system call interface must be expanded to include new stateless calls

14. Performance Analysis Is it worthwhile to architect an application as a multi-threaded system? –cost time spent in initialization fork and join time context switch time per operation synchronization time –benefits possibility of increased throughput

15. Microbenchmark Results- Lock/Unlock

16. Microbenchmark Results-Fork

17. Microbenchmark Results-Yield

18. Analytic Model Reasons to use threads package –application is most naturally structured using multiple threads –threads package that run both on uniprocessors and multiprocessors –application may benefit from increased parallelism

19. Cost-Benefit Model Consider a scenario of Database Server: –disk requests takes 19 times longer than cache requests –cache has a 95% hit ratio Amount of time servicing disk requests: 19 x 0.05 = 0.95 Amount of time servicing cache requests: 1 x 0.95 = 0.95

20. Conclusions well suited for uniprocessors straightforward to implement Scheduler Activations allows application to manage its threads at user level overhead of using Scheduler Activations is less than 10% of cost of I/O