Jonas Johansson

Summarizing presentation of

Scheduler Activations–

A different approach to parallelism

Contents

Introduction

The Problem The Approach Result Legacy Summary Conclusions and comments

Introduction – About the paper

Written in 1991 Authors:

Anderson, Bershad, Lazowska, Levy University of Washington (Seattle)

Summary Describes drawbacks to the management of

parallelism (the way it was back in 1991) Suggests a new solution (”scheduler activations”) Compares performance (old methods, scheduler

activations)

Introduction – Ambition of this presentation

Give an understanding of: the characteristics of kernel threads and

user-level threads the scheduler activations approach

Tie this to topics covered in this course Parallelism Lock holding threads (e.g. mutexlock) I/O, blocking

Introduction - Threads review

Threads Several threads in each process Parallelism Share address space, system resources (e.g. files

and terminals) etc. Less overhead when exchanging data between

threads compared to inter-process communication (due to shared memory etc)

Two types of threads: Kernel threads User-level threads

Address space

Files Code

Multithreaded process

Introduction – Kernel and User-level threads

Applications

Kernel

CPU Memory Devices

User level

Kernel level

System resources

Introduction – Kernel threads

Application

CPU1 CPU2

User level

Kernel level KERNEL

System resources

The kernel will create the threads

The kernel is also responsible for thread scheduling

Introduction – Kernel threads

Kernel threads Supported directly by the Operating

system The kernel handles:

Thread creation Thread scheduling Thread management

Introduction – Kernel threads

Kernel threads

+ -

The kernel controls all thread management -> Good functionality!

Many kernel calls -> Slow!

No system integration problems; Kernel manages threads

To modify the thread system means modifying the kernel -> Difficult!

+ Good functionality– Poor performance and flexibility

Introduction – User-level threads

Application

CPU1 CPU2

User level

Kernel level

System resources

Threads are created at user level

Thread scheduling is done at user level

The user threads are mapped onto kernel threads (here 1 thread/processor“User-level threads are built on top of kernel threads”

Thread library

Introduction – User-level threads

User-level threads Implemented by a thread library at user

level Creation, scheduling and management of

threads without support from the kernel Creation and management is fast

Built on top of kernel threads

Introduction – User-level threads

User level threads

+ -

Can be modified at user-level -> Flexible!

System integration problems

Less kernel calls -> Fast! I/O, page faults etc are handled by the kernel (not seen from the user level) -> Not functional!

+ High performance and flexibility – Poor functionality

Introduction – Simplified

Kernel threads ”work right” but perform poorly, user-level threads perform well but doesn’t always “work right”

Problem

Problem – in brief

”Threads can be supported either at user level or in the kernel. Neither approach has been fully satisfactory.”

Problem – Simplified summary

2 main problems in traditional thread systems

1. The user-level is not informed of kernel events such as I/O blocking

Processor lost during the block

2. Kernel threads are scheduled without regard to the user-level thread state

Lock-holding threads can be de-scheduled

In other words: Communication between the kernel and the user level is not good enough…

Approach

”Scheduler activations” A newly designed kernel interface A new user-level thread system

Note that this is still a user-level approach but with a new kind of kernel support

Scheduler activations ≈ User-level thread system with better communication and interaction with the kernel

Approach – Scheduler activations

Approach – What does what?

Scheduler activations

User level Thread scheduling;Decides the number of threads and when to execute each thread

Communication: Notifies the kernel when more or fewer processors are needed

The kernel Processor allocation;Decides how many processors an application is given

Communication: Notifies the user level of all the events that affect thread scheduling

Approach

Why called Scheduler activation? The scheduler is activated when it needs to

make a decision about scheduling The key point is communication between

the kernel and the user level

KERNEL

Approach – Illustration of startup

Application

VCPU2VCPU1

Memory space

CPU1 CPU2

User level

Kernel level

•An application is started•The kernel creates a scheduler activation and assigns this to a processor•The same processor is used to start running the thread•When the program runs more threads will be created•More threads than processors ->A new scheduler activation is created…

KERNEL

Approach – Illustration of communication

Application Application

VCPU2VCPU1

Memory space Memory space

VCPU1 VCPU2 VCPU3

CPU1 CPU2 CPU3 CPU4 CPU5

User level

Kernel level

!Want more CPUs

This processor has been preempted

Add this processor

This processor is idle

Problem – Simplified summary

Main problems in traditional thread systems

1.The user-level is not informed of kernel events such as I/O blocking Processor lost during the block

2. Kernel threads are scheduled without regard to the user-level thread state Lock-holding threads can be descheduled

In other words: Communication between the kernel and the user level is not good enough…

Approach – Blocking

With user-level threads When a user-level thread blocks, its kernel

thread also blocks The physical processor is lost during the block

With scheduler activations The user-level is informed about the block and

can therefore run another thread on the processor

When unblocked, the user-level is informed and can choose which thread to schedule next

Problem – Simplified summary

Main problems in traditional thread systems

1.The user-level is not informed of kernel events such as I/O blocking Processor lost during the block

2. Kernel threads are scheduled without regard to the user-level thread state Lock-holding threads can be de-scheduled

In other words: Communication between the kernel and the user level is not good enough…

Approach – Scheduling

With user-level threads Timeslicing of kernel threads Processor idle while waiting for a lock

holding thread that has been de-scheduled

With scheduler activations The user level:

Knows when a thread is holding a lock Is responsible for all of the scheduling

Will not de-schedule lock holders

Result

Result – Effects of scheduler activations

Performance Functionality Flexibility

Result – Measuring performance

Performance Measured by running a parallel application

with Little use of kernel services (100%

memory) Much use of kernel services (limited

memory) Blocking…

Two simultaneous applications (100% memory) Lock-holding threads…

Result – Performance – Little use of kernel services

Topaz = Kernel threadsorig = User-level threadsnew = Scheduler activations

Almost no I/O Speedup compared to

sequential implementation Scheduler activations

perform as good as user-level threads

Topaz = Kernel threadsorig = User-level threadsnew = Scheduler activations

Much use of I/O Working set stops

fitting into memory at about 50% -> kernel services

Scheduler activations and kernel threads Handle I/O in a good

way User- level threads

Physical processor is lost during I/O blocks

Result – Performance – Much use of kernel services

Simultaneous applications Two copies of the same program This will also generate kernel events

(system-induced events)

Performance difference User-level – Time slicing gives idling processors Kernel level – ”Expensive” thread operations

Result – Performance – Much use of kernel services

Thread system Speed-up

Kernel threads: 1.29User-level threads: 1.26Scheduler activations:

2.45

Result – Effects of scheduler activations

Performance Functionality Flexibility

Pass

Result – Functionality

Functionality Same as kernel threads (even with I/O,

page faults, multiprogramming) No idle processor when there are ready threads When a thread blocks, the processor that was

running that thread must be able to run another thread during the block

Pass

Pass

Result – Effects of scheduler activations

Performance Functionality Flexibility

Pass

Pass

Goal: Simple application-specific customization The kernel is unaware of the scheduling

policies All scheduling is decided at user level (by

the programmer)

Result – Flexibility

The programmer can modify the policy for scheduling decisions relatively easily

Pass

Result – Effects of scheduler activations

Performance Functionality Flexibility

Pass

Pass

Pass

Results – Summary

Goals were met Performance

Equal or better than user-level thread performance Great performance increase when dealing with I/O

Functionality Equal to that of kernel threads

Flexibility Programming an application using scheduler

activations is similar to traditional multiprogramming However…

Legacy

To implement there is a need of modifying both user space code and the kernel – Hard!

Implemented in NetBSD kernel by Nathan Williams FreeBSD - KSE project (threading system

similar to Scheduler activations) Later replaced with kernel threads Scheduler activations has been

implemented mostly for research purposes

Summary

Comparison of thread systems

Thread system + -

User-level High performance: Often very fast!

Poor functionality: Blocking etc.

Kernel Good functionality: ”Works well”

Low performance:Overhead

Scheduler activations

High performance, good functionality

Hard to implement in an OS

Conclusion and comments

Suffers from none of the weaknesses with user-level and kernel level threads

Logical approach – ”makes sense” Complex implementation still makes it

worse than the traditional approaches Implementation: Though important, only

briefly covered in the paper

Jonas Johansson

Summarizing presentation of

Scheduler Activations–

A different approach to parallelism