Scheduling in Operating systems

Scheduling in Operating systems Giuseppe Lipari http://retis.sssup.it/~lipari LSV – Ecole Normale Supérieure de Cachan

January 6, 2014

G. Lipari (LSV)

Scheduling in Operating systems

January 6, 2014

1 / 25

Outline

1

Introduction

2

Case study: Linux

3

Multicore

4

Energy

G. Lipari (LSV)


January 6, 2014

2 / 25

Operating System

An operating system is a program that Provides an “abstraction” of the physical machine through a simple interface Each part of the interface is a “service”

An OS is also a resource manager With the term “resource” we denote all physical entities of a computing machine The OS provides access to the physical resources The OS provides abstract resources (for example, a file, a virtual page in memory, etc.)

One of such services is scheduling of concurrent processes

G. Lipari (LSV)


January 6, 2014

3 / 25

Virtual processor

An OS provides “concurrency” between processes Many processes are executed at the same time in the same system Each process executes for a fraction of the processor bandwidth (as it were on a dedicated slower processor)

Provided by the scheduling sub-system Provided by almost all OS, from nano-kernels to general-purpouse systems

G. Lipari (LSV)


January 6, 2014

4 / 25

Classification of Operating Systems

The level of abstraction and the type of services depend on the application context General purpouses OS should provide a wide range of services to satisfy as many users as possible Specialised OS provide only a set of specialised services

OS one meaningful classification is based on the application context General purpose (Windows, Linux, etc), Servers, Embedded OS (iOS, Android) Deeply embedded (e.g. OS for automotive, OS for WSN) RTOS (VxWorks, Neutrino, QNX, Embedded Linux, etc.)

G. Lipari (LSV)


January 6, 2014

5 / 25

Objective The role of the scheduler is to execute the active threads in a certain order on the processors, so to achieve a certain goal THE PROBLEM: Goals may be application-specific or system-wide Example of application specific goals: a real-time application needs predictability, its threads must complete before their deadlines Multimedia applications need smooth playback Large parallel scientific applications need to minimise makespan (completion time)

Example of system-wide goals: Smartphones need to save as much energy as it is possible Web-servers needs to maximise throughput (number of requests served per second) but also to spare energy (to save on electrical bills)

Often contrasting goals G. Lipari (LSV)


January 6, 2014

6 / 25

General purpose vs. specific Scheduling is a system-wide service In a general purpose OS it is difficult to take into account application-specific objectives Therefore, GPOS often resort to provide fairness among applications and responsiveness All threads receive a fair share of execution time for I/O bound threads, try to minimise response time

On dedicated systems, it is possible to optimise the scheduling to specific needs For example, in embedded real-time systems, the application has well-known characteristics that can be exploited to achieve a specific goal (e.g. predictability)

G. Lipari (LSV)


January 6, 2014

7 / 25

Outline

1

Introduction

2

Case study: Linux

3

Multicore

4

Energy

G. Lipari (LSV)


January 6, 2014

8 / 25

Linux scheduling hierarchy Linux uses a scheduling hierarchy organised into scheduling classes

G. Lipari (LSV)


January 6, 2014

9 / 25

Completely Fair Scheduler The CFS1 is a variant of the Weighted Fair Scheduler WF 2 Q [BZ96] It uses a red-black tree to store process descriptors ordered by “virtual runtime” The one with the smallest vr is executed on the processor

1

http://www.ibm.com/developerworks/linux/library/l-completely-fa G. Lipari (LSV)


January 6, 2014

10 / 25

Linux RT class 100 99

Each thread is assigned a fixed priority

REAL−TIME PRIORITIES

98

(SCHED_FIFO OR SCHED_RR)

One queue per priority (1-100) Threads with the same priority execute in round-robin (SCHED_RR) in FIFO (SCHED_FIFO)

1

0 NON REAL−TIME PRIORITIES

−1

(SCHED_OTHER) −39

G. Lipari (LSV)


January 6, 2014

11 / 25

Linux and RT

The main problem in using Linux for Real-Time is latency Many activities may delay urgent user threads: Many kernel threads may have higher priority Interrupt handling routines always have priority over user threads Many sections of kernel code are non-interruptible and non-preemptible

Delay in executing a user thread by be as high as 50 mseconds on stock Linux

G. Lipari (LSV)


January 6, 2014

12 / 25

Linux Preemptive Kernel

When configuring Linux, it is possible to enable the “Preemptive kernel” option It modifies Linux code as follows: Almost all interrupt handlers become kernel threads with their own priority Every critical section of code is guarded by semaphore with the Priority Inheritance Protocol2

In this way, the worst-case latency is greatly reduced at the expenses of an increase in average case overhead

2

TBD: Link to section G. Lipari (LSV)


January 6, 2014

13 / 25

Outline

1

Introduction

2

Case study: Linux

3

Multicore

4

Energy

G. Lipari (LSV)


January 6, 2014

14 / 25

Multi-processor scheduling

Two approaches Partitioned Threads are allocated to processors One different scheduling queue per processor

Global Thread can migrate arbitrarily one single queue for all processors

Clustered (mix of the two) Processors are divided into clusters, one queue per cluster threads are allocated to clusters

G. Lipari (LSV)


January 6, 2014

15 / 25

SMP in Linux In Symmetric Multiprocessors (SMP), or even in Non-Uniform Memory Architectures (NUMA), Linux works as follows: One instance of the Linux kernel code may run on every processor All instances share the same data structures If a user thread running on processor x calls a kernel service, this is executed on the same processor x Interrupts are routed from I/O to processors thanks to the APIC architecture It is possible to send an interrupt from one processor to another one for synchronisation

The scheduler is organised as follows One run-queue per each processor Every instance can access every run-queue (for migration)

G. Lipari (LSV)


January 6, 2014

16 / 25

Multi-processor scheduling The CFS scheduler Threads can start running on any processor, and they are inserted in the corresponding run-queue Periodically, an heuristic function tries to perform load balancing It is possible to restrict the set of processor on which a thread may migrate by setting processor affinities for the thread It is possible to set a bit-mask (one bit per processor), for deciding which processor may run a specific thread

Run-queues are shared data structures that may be accessed by all processors Difficult synchronisation problem (how to maximise concurrency and avoid deadlock?)

G. Lipari (LSV)


January 6, 2014

17 / 25

Migration

Suppose we need to move a thread from processor x to processor y. Simple strategy: Lock x, then y Update the two run-queues unlock y, then x

This may bring to a deadlock! One single lock is not a solution because it does not scale with the number of processor Solution?

G. Lipari (LSV)


January 6, 2014

18 / 25

Real-Time scheduling Each run-queue is implemented as a red-black tree, ordered by priority Push-pull mechanism When a schedule() is called on processor x, it looks at all other run-queues to select which thread has the higher priority and the correct affinity Once it selects a thread, it may perform a migration (pull) It also looks to see if there is a free processor that can execute the second thread in the run-queue, in which case it performs a migration (push)

The algorithm always looks at all run-queues To speed it up, another global data structure is used to identify which processor is empty, and which one has the highest priority thread Synchronisation becomes even more complex!

G. Lipari (LSV)


January 6, 2014

19 / 25

SCHED_DEADLINE A new scheduling class developed at Scuola Superiore Sant’Anna [LLFC11] Candidate for inclusion in next version of the Linux kernel

Implements the Earliest Deadline First algorithm with budgeting Main features: Run-queues are red-black trees ordered by deadlines A sorted heap keeps track of the earliest deadline on each processor The heap is protected by a lock in writing, while the read is lock-free (atomic) when updating the data structures, locks are taken always in the same order the read operation is repeated inside the locks, and if it gives a different result, it is aborted and will be retried

G. Lipari (LSV)


January 6, 2014

20 / 25

Outline

1

Introduction

2

Case study: Linux

3

Multicore

4

Energy

G. Lipari (LSV)


January 6, 2014

21 / 25

Scheduling and energy

It is possible to save energy by taking advantage of idle times We can do it in two possible ways: Reducing the voltage Turning off parts of the hardware (e.g. processors)

Power consumption consists of 2 parts: Static power (always present if the processor is working) Dynamic power (a function of the operative voltage and frequency)

G. Lipari (LSV)


January 6, 2014

22 / 25

DVFS vs. DPM Dynamic Voltage and Frequency Scaling Reducing the voltage reduces dynamic power consumption Voltage reduction → clock frequency reduction → processor becomes slower → idle time disappears If too aggressive, the user may be unhappy (too slow!)

The saving depends on How much the dynamic power depends on the voltage, and the relationship between voltage and frequency The relationship between static power and dynamic power

Dynamic Power management consists in turning off the processor during idle time however, turning it on again may take some (long) time therefore it may not be possible if we need short response times

G. Lipari (LSV)


January 6, 2014

23 / 25

Scheduling

What this has to do with scheduling? The scheduler can be used to identify idle times The scheduler can “compact” many idle times together In multi-core system we can do “load unbalancing” to compact all threads on a smaller number of processors, so to turn off the unused ones

Other possible constraints: temperature! In that case, we need to migrate threads, so to turn off processors that became too hot

Putting all things together is still a very open problem [BLBL13]

G. Lipari (LSV)


January 6, 2014

24 / 25

Bibliography I

[BLBL13] Mario Bambagini, Juri Lelli, Giorgio Carlo Buttazzo, and Giuseppe Lipari, On the Energy-Aware Partitioning of Real-Time Tasks on Homogeneous Multi-Processor Systems, Proceedings of the 4th International Conference on Energy Aware Computing Systems and Applications , December 2013. [BZ96]

J.C.R. Bennett and H. Zhang, WF2Q: Worst-case Fair Weighted Fair Queueing, Proc. of INFOCOM’96, March 1996.

[LLFC11] Juri Lelli, Giuseppe Lipari, Dario Faggioli, and Tommaso Cucinotta, An efficient and scalable implementation of global EDF in Linux, Proceedings of the International Workshop on Operating Systems Platforms for Embedded Real-Time Applications (OSPERT), 2011 2011.

G. Lipari (LSV)


January 6, 2014

25 / 25