OSE 2011– OS scheduling1

Operating Systems Engineering

OS Scheduling

By Dan Tsafrir, 27/4/2011

OSE 2011– OS scheduling2

What’s OS scheduling

OS policies & mechanisms to allocate resources to entities Enforce a policy (e.g., “shortest first”) Using an OS mechanism (e.g., “thread chooser”)

Entities Threads, processes, process groups, users, I/O ops (web

requests, disk accesses…) Resources

CPU cycles, memory, I/O bandwidth (network, disk) Dynamic setting

Usually scheduling must occur when resources re-assignment can happen with some frequency

Not applicable to more static resources (like disk space) Varying scale

From shared memory accesses (HW) to parallel jobs (SW)

OSE 2011– OS scheduling3

Overload

Scheduling unavoidable When resources are shared

But it’s mostly interesting in a state of overload When demand exceeds available resources E.g., if |threads| <= |cores|, scheduling is trivial

Well, not really, as threads placement might impact performance greatly (caches are shared)

For parallel jobs on, say, the Bluegene supercomputer, this example is more or less true

Likewise, in the cloud, when there are more physical servers than VMs (and you’re willing to pay for power)

A good scheduling policy Gives the most important entity what it needs Equally important => fair share

OSE 2011– OS scheduling4

Popularity of OS scheduling research

Especially popular in the days of time-sharing When there was a shortage of resources all around

Many scheduling problems become uninteresting When you can just cheaply buy more/faster resources

But there were always important exceptions Web servers handling peak demands (flash crowds, attacks,

prioritizing paying customers) And nowadays…

Embedded (power/performance considerations on your handheld device)

Cloud servers

OSE 2011– OS scheduling5

Key challenges

Knowing what’s important Can’t read clients’ mind; often unrealistic to explicitly ask

Many relevant, often conflicting performance metrics Throughput vs. latency (e.g., network packets) Throughput vs. fairness (e.g., DRAM accesses) Power vs. speed (e.g., DVFS) Soft/hard realtime …

Many schedulers CPU, disk, I/O, memory,… Interaction not necessarily healthy

Countless domain-specific, workload-dependent, ad-hoc solutions No generic solution

OSE 2011– OS scheduling6

Addressing challenges – baseline

1. Understand where scheduling is occurring

2. Expose scheduling decisions, allow control, allow different policies

3. Account for resource consumption to allow intelligent control

OSE 2011– OS scheduling7

Multilevel priority queue

Running reduces priority to run more Multiple ready queues, ordered by importance Run most important first in a round-robin fusion Use preemption if more important process enters the system The negative feedback loop ensures no starvation If you sleep a lot => consume little CPU => you’re important

=> when awakened, you’d typically immediately get a CPU

Used by all general-purpose OSes Unix family, Windows family

Problematic in many respects What if you run a lot but are still very important to the user?

OSE 2011– OS scheduling8

Pitfall: priority inversion

Example One CPU P_low holds a lock P_high waits for it P_med becomes runnable => OS preempts P_low (From real life: exactly what happened in 1st Mars Rover)

Example Many CPU-bound background processes X server serves multiple clients => CPU quota might run out

Possible solution: priority inheritance P_high lends its priority to P_low until key is released X clients lend their priority to X server until serviced

OSE 2011– OS scheduling9

Pitfall: uncoordinated schedulers

Example Even though CPU-scheduler favors emacs (always sleeps), disk I/O scheduler does not, preferring higher throughput

over emacs’s I/O ops

Example Emacs needs memory => memory is tight => must wait Other processes have dirty pages => write to disk Disk I/O scheduler doesn’t know these writes are important

OSE 2011– OS scheduling10

Active field of research

“No justified complaints: On fair sharing of multiple resources”

[Dec, 2010; Dolev, Feitelson, Linial et. Al; TR]

“We define fairness in such a scenario as the situation where every user either gets all the resources he wishes for, or else gets at least his entitlement on some bottleneck resource, and therefore cannot complain about not getting more.

We then prove that a fair allocation according to this definition is guaranteed to exist for any combination of user requests and entitlements. The proof, which uses tools from the theory of ordinary differential equations, is constructive and provides a method to compute the allocations numerically.”

OSE 2011– OS scheduling11

Active field of research

“RSIO: Automatic User Interaction Detection and Scheduling”

[Jun 2010; Zheng, Viennot, Nieh; SIGMETRICS]

“We present RSIO, a processor scheduling framework for improving the response time of latency-sensitive applications

by monitoring accesses to I/O channels and inferring when

user interactions occur.

RSIO automatically identifies processes involved in a user interaction and boosts their priorities at the time the interaction occurs to improve system response time.

RSIO also detects processes indirectly involved in processing an interaction, automatically accounting for dependencies and boosting their priorities accordingly.”

OSE 2011– OS scheduling12

Active field of research

“Secretly monopolizing the CPU without superuser privileges”

[Aug 2007; Tsafrir, Etsion, Feitelson; USENIX Security]

See next presentation…