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

Outline Scheduler Activation Model Implementation Performance Analysis Analytic Model Conclusions

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

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

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

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

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

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

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

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?

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

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

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

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

Microbenchmark Results- Lock/Unlock

Microbenchmark Results-Fork

Microbenchmark Results-Yield

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

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

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