Scheduler Activations On BSD: Sharing Thread Management Between Kernel and Application

1
Scheduler Activations On BSDSharing Thread
Management BetweenKernel 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 packageMyth

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_initinitialize the thread package and creates
  mp-1 virtual processors
• th_fork(func,arg)forks a new child thread
• th_yieldyield the virtual processor to another
  thread
• th_joinwait for the termination of specified
  thread and accept its return value
• supports synchronization primitiveslocking

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