User-Level Management of Parallelism: Scheduler Activations

 
Scheduler Activations
Effective Kernel Support for the User-Level Management of Parallelism
 
Thomas E. Anderson
Brian N. Bershad
Edward D. Lazowska
Henry M. Levy
 
University of Washington
 
1
 
Problem
 
Threading increasing in popularity
Kernel-level and user-level threads are the only options
 
2
 
Kernel-level Threads
 
“1:1 model”
Kernel creates, schedules, synchronizes, etc
Thread blocking doesn’t affect the rest of the process
 
3
 
Kernel-level threading downsides
 
High overhead of system calls
Generalized
 
4
 
User-level threads
 
“N:1 model”
FSU Pthreads, PTL2, FastThreads
Self scheduling with specialized scheduling algorithms
More flexibility
Lightweight
 
 
5
 
User-level thread downsides
 
Purely user-level threading can only use one processor
Operations that block (I/O, page fault) block entire process
 
6
 
Unix Processes < Kernel threads < User threads
 
7
 
Scheduler Activations
 
“N:M model”
Processes each given a “virtual processor”
User-level scheduling
Low cost of creating, swapping, etc
Multiprocessor
 
8
 
General Approach
 
Kernel allocates processors to each process
Applications know what processors they have been allocated
Requires communication
 
9
 
Communication
 
Kernel notifies application when
granting additional processor
A processor is preempted
Thread blocks, or finished blocking in Kernel
User level notifies kernel when
 
It requires more or less processors
 
10
 
Scheduler Activations
 
Each thread has its own SA
Given when thread starts on processor
Two execution stacks (one kernel, one user space)
 
11
 
Upcalls and System Calls
 
Kernel talks to the application through upcalls
Application talks to kernel through system calls
 
12
 
13
 
14
 
15
 
16
 
17
 
18
 
19
 
20
 
21
 
22
 
23
 
24
 
25
 
Critical Sections
 
Potential issues
Prevention vs. Recovery
Upcall handler executes thread
 
26
 
Implementation
 
DEC SRC Firefly multiprocessor workstation
Modified Topaz OS
Modified FastThreads user-level thread package
 
27
 
Implementation con’t
 
Guarantees no processor to idle if work can be done
Even distribution of processors among high priority address spaces
Continued support for standard Kernel threads
Applications free to chose scheduling algorithm
Processors wait short time before notifying kernel for reallocation
 
28
 
Optimizations
 
Critical Sections
Flags have high overhead
Copy critical section code instead
Recycling Scheduler Activations
 
29
 
Performance
 
What is the cost of user-level thread operations?
What is the cost of communication?
What is the effect on application performance?
 
30
 
Thread Operation Performance
 
31
 
Communication Cost
 
More expensive than current kernel thread operations
Potential optimizations could bring it even with Topaz kernel thread operations
 
32
 
Application Performance
 
Tested against O(n * log(n)) solution of N-body problem
 
33
 
34
 
35
 
36
 
NetBSD Implementation
 
System call latency measured on a 500 MHz
Digital Alpha 21164 system
 
 
 
 
 
 
 
Thread operation costs mesaured on an Apple
iBook with a 500MHz G3 processor and 256k of
L2 cache
 
37
 
Discussion Points
 
Scheduler Activations require a process to be honest about the number of threads required.  What
strategy could be utilized to ensure fairness even in dishonest conditions?
What workloads / processes would be ideal for Scheduler Activations over User-level threading?
How do threads compare to goroutines?
 
38
 
Goroutines
 
3 Major differences
 
Memory consumption
 
Setup / Teardown
 
Switching
Handling blocks
Synchronization
 
39
Slide Note

[ Introduce Paper ]

1991 SOSP Conference

Another paper which I used as a reference, and will be mentioning explicitly later in the presentation was

An Implementation of Scheduler Activations on the NetBSD Operating System

Nathan J. Williams

Wasabi Systems, Inc.

Embed
Share

This content delves into the comparison between kernel-level threads and user-level threads in managing parallelism. It discusses the challenges and benefits associated with each threading model, highlighting the trade-offs between system overhead, flexibility, and resource utilization. The concept of Scheduler Activations is explored, presenting a user-level approach for efficient management of parallelism through virtual processors and low-cost scheduling.

  • Parallelism Management
  • Scheduler Activations
  • Kernel Threads
  • User Threads
  • Process Scheduling

Uploaded on Oct 04, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Scheduler Activations Effective Kernel Support for the User-Level Management of Parallelism Thomas E. Anderson Brian N. Bershad Edward D. Lazowska Henry M. Levy University of Washington 1

  2. Problem Threading increasing in popularity Kernel-level and user-level threads are the only options 2

  3. Kernel-level Threads 1:1 model Kernel creates, schedules, synchronizes, etc Thread blocking doesn t affect the rest of the process 3

  4. Kernel-level threading downsides High overhead of system calls Generalized 4

  5. User-level threads N:1 model FSU Pthreads, PTL2, FastThreads Self scheduling with specialized scheduling algorithms More flexibility Lightweight 5

  6. User-level thread downsides Purely user-level threading can only use one processor Operations that block (I/O, page fault) block entire process 6

  7. Unix Processes < Kernel threads < User threads 7

  8. Scheduler Activations N:M model Processes each given a virtual processor User-level scheduling Low cost of creating, swapping, etc Multiprocessor 8

  9. General Approach Kernel allocates processors to each process Applications know what processors they have been allocated Requires communication 9

  10. Communication Kernel notifies application when granting additional processor A processor is preempted Thread blocks, or finished blocking in Kernel User level notifies kernel when It requires more or less processors 10

  11. Scheduler Activations Each thread has its own SA Given when thread starts on processor Two execution stacks (one kernel, one user space) 11

  12. Upcalls and System Calls Kernel talks to the application through upcalls Application talks to kernel through system calls 12

  13. 13

  14. 14

  15. 15

  16. 16

  17. 17

  18. 18

  19. 19

  20. 20

  21. 21

  22. 22

  23. 23

  24. 24

  25. 25

  26. Critical Sections Potential issues Prevention vs. Recovery Upcall handler executes thread 26

  27. Implementation DEC SRC Firefly multiprocessor workstation Modified Topaz OS Modified FastThreads user-level thread package 27

  28. Implementation cont Guarantees no processor to idle if work can be done Even distribution of processors among high priority address spaces Continued support for standard Kernel threads Applications free to chose scheduling algorithm Processors wait short time before notifying kernel for reallocation 28

  29. Optimizations Critical Sections Flags have high overhead Copy critical section code instead Recycling Scheduler Activations 29

  30. Performance What is the cost of user-level thread operations? What is the cost of communication? What is the effect on application performance? 30

  31. Thread Operation Performance 31

  32. Communication Cost More expensive than current kernel thread operations Potential optimizations could bring it even with Topaz kernel thread operations 32

  33. Application Performance Tested against O(n * log(n)) solution of N-body problem 33

  34. 34

  35. 35

  36. 36

  37. NetBSD Implementation System call latency measured on a 500 MHz Digital Alpha 21164 system Thread operation costs mesaured on an Apple iBook with a 500MHz G3 processor and 256k of L2 cache 37

  38. Discussion Points Scheduler Activations require a process to be honest about the number of threads required. What strategy could be utilized to ensure fairness even in dishonest conditions? What workloads / processes would be ideal for Scheduler Activations over User-level threading? How do threads compare to goroutines? 38

  39. Goroutines 3 Major differences Memory consumption Setup / Teardown Switching Handling blocks Synchronization 39

More Related Content

giItT1WQy@!-/#