resource management for computer operating systems sarah bird phd candidate berkeley eecs burton...
TRANSCRIPT
Resource Management for Computer Operating Systems
Sarah BirdPhD CandidateBerkeley EECS
Burton SmithTechnical Fellow
Microsoft
Background• Management of computing resources is a
primary operating system responsibility– It lets multiple applications share a single system
• These days, we face new challenges– Increasing numbers of cores (hardware threads)– Emergence of parallel applications– Quality of Service (QoS) requirements– The need to manage power and energy
• Current practice fails to address these issues– Thread management is a good example
Windows Thread Management• Windows maintains queues of runnable threads
– One queue per priority per core• Each core chooses a thread from the head of its nonempty queue
of highest priority and runs it• The thread runs for a “time quantum” unless it blocks or a higher
priority queue becomes nonempty• Thread priority can change at scheduling events, with a new
priority based on what just happened:– One thread unblocking another– I/O completion (keyboard, mouse, storage, network)– Preemption by a higher priority thread– Time quantum expiration– New thread creation
• Other operating systems are pretty similar
Some Obvious Shortcomings• Operating system thread scheduling is costly– It incurs (needless) changes in protection– User mode thread scheduling is much cheaper
• Thread progress is unpredictable– Lock-free techniques were invented to avoid this
• Processes have no control over threads– Despite their big role in memory management
• Response times are impossible to guarantee– What number of threads is enough for a process?
• Power and energy are ignored
A Way Forward• Resources should be allocated to processes– Cores of various types– Memory (working sets)– Bandwidths, e.g. to shared caches, memory, storage
and interconnection networks• The operating system should:– Optimize the responsiveness of the system– Respond to changes in user expectations– Respond to changes in process requirements– Maintain resource, power and energy constraints
What follows is a scheme to realize this vision
Responsiveness• Run times determine process responsiveness– The time from a mouse click to its result– The time from a service request to its response– The time from job launch to job completion– The time to execute a specified amount of work
• The relationship is usually a nonlinear one– Achievable responses may be needlessly fast– There is generally a threshold of acceptability
• Run time depends on the resources– Some resources will have more effect than others– Effects will often vary with computational phase
Penalty Functions• The penalty function of a process defines how run
times translate into responsiveness– Its shape expresses the nonlinearity of the relationship– The shape will depend on the application and on the
current user interface state (e.g. minimized)• We let the total penalty be the instantaneous sum
of the current penalties of the running processes– Resources determine run times and therefore penalties
• Assigning resources to processes to minimize the total penalty maximizes system responsiveness
Typical Penalty Functions
Run time
Pena
ltyDeadline
Run time
Pena
lty
Adjusting Penalty Functions• Penalty functions are like priorities, except:– They apply to processes, not kernel threads– They are explicit convex functions of the run time
• The operating system can adjust their slopes– Up or down, based on user behavior or preference– The deadlines can probably be left alone
• The total penalty is easy to compute– The objective is to keep minimizing it
Run Time Functions• Generally, they exhibit “diminishing returns”
as resources are added to a process– That is, run times are generally convex functions
• They vary with input and must be measured– Sometimes run time increases with some resource– We may see “plateaus” or various types of “noise”
Run
time
Memory allocation
Resource Allocation As OptimizationContinuously minimize pP p(p(rp,0, … rp,n-1) with
respect to the resource allocations rp,j , where
• P, p, p, and the rp,j are all time-varying;• P is the set of runnable processes;• rp,j 0 is the allocation of resource j to process p;
• The penalty p depends on the run time p;
• p depends in turn on the allocated resources rp,j;
• pP rp,j = Aj , the available quantity of resource j.– All unused (slack) resources are allocated to process 0
The Optimization Picture
Runtime1(r(0,1), …, r(n-1,1)) Runtime1
Pena
lty1Continuously
minimize the total penalty
Runtime2 (r(0,2), …, r(n-1,2)) Runtime2
Runtimei(r(0,i), …, r(n-1,i)) Runtimei
Pena
lty2
Pena
ltyi
Subject to the total available resources
Convexity and Concavity• A function f is convex if for all x, y in n, in , and
0 1, f(x + (1−)y) f(x) + (1−)f(y)– Chords of the function’s graph must lie on or above it
• A function f is concave if for all x, y in n, in , and0 1, f(x + (1−)y) f(x) + (1−)f(y)– Alternatively, f is concave if and only if –f is convex
• Affine functions Ax + b are both convex and concave• If functions fi are convex so is their sum i fi
• If functions fi are convex so is their maximum maxi fi • If f is both convex and monotone non-decreasing and g is convex then
h(x) = f(g(x)) is convex• If f is convex, so is the set C = { xdom(f) | f(x) }
– C is called the -sublevel set of f
Convex Optimization• A convex optimization problem has the form:
Minimize f0(x1, … xm)
subject to fi(x1, … xm) 0, i = 1, … k
where the functions fi : Rm R are all convex• Convex optimization has several virtues– It guarantees a single global extremum– It is not much slower than linear programming
• In our formulation, resource management is a convex optimization problem
Managing Power and Energy• Total system power can be limited by an affine resource
constraint j wj · p 0 rp,j W
• Total power can also be limited using 0 and 0
– Assume all slack resources r0,j are powered off
– Instead of being a run time,0 is total power• It will be convex in each of the slack resources r0,j
– 0 has a slope that can depend on the battery charge• Low-penalty work loses to 0 when the battery is depleted
Total Power
Pena
lty
As charge depletes,slope increases
a0,r
Tota
l Pow
er
Modeling Run Times• Run time measurements can be used to
construct a model, yielding several advantages– “Noise” can be removed while building the model– Interpolation among measurements is avoided– Rates of change with resources are computable
• We have constructed several types of model– Linear and quadratic (rate) models– Kernel Canonical Correlation Analysis– Genetically Programmed Response Surfaces– Most recently, convex run time models
Convex Models 17
w: learned parametersb: bandwidth allocations: bandwidth amplificationsm: memory allocations
ji ji
ji
bb
wTbw
,
,0
*),(
3
3
2
2
1
10),(
b
w
m
w
b
wTbw
i iii
i
mb
wTmbw
0),,,(
Modeling Results• Our convex models fit the data very well– We are now seeing how they work in practice
• We think linear least-squares applied to past run time data can learn the model parameters– The QR matrix factorization can be updated and
downdated to track changes in process behavior• We have also discovered some interesting
artifacts along the way…
0 500 1000 1500 2000 2500 3000 35000
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.22
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Memory Pages
Seco
nds
Nbodies Frame Time
Nbodies Frame Time
0 500 1000 1500 2000 2500 3000 35000.00333333333333333
0.0333333333333333
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16Memory Pages
Seco
nds
PACORA• PACORA stands for “Performance-Aware Convex
Optimization for Resource Allocation”– See our paper in the poster session of HotPar ‘11
• It manages resource allocation policy in the Berkeley ParLab’s Tesselation operating system– One of us (Bird) is currently implementing it
• Nearly all of the ideas presented here are being prototyped in PACORA and in Tesselation– If these ideas work they may be used elsewhere
24
Policy S
erv
ice
MajorChangeRequest
ACK/NACK
App Creation
and Resizing
Requestsfrom Users
Admission
Control
MinorChanges
ACK/NACK
App App App
All system
resources
App group with
fraction of resources
App
Current Application
Store
(Current Resources)
Global Policies /User Policies andPreferences
Offline Modelsand Behavioral
Parameters
Build and Refine
Resource Value
Functions
App
#1
App
#2
App
#3
User/System
Perfo
rman
ce
Repo
rts
Convex Optimization
Set Penalty Functions
Decision Validation
PACORA in Tessellation
Resource Allocations
Performance/Energy Counters
Acknowledgements• Stephen Boyd and Lieven Vandenberghe, whose
book taught us about convex optimization• Krste Asanović, David Patterson, and John
Kubiatowicz at Berkeley, for their strong support• The Microsoft Windows developers, for giving
us real applications and ways to measure them• Colleagues at the UC Berkeley ParLab and at
Microsoft Research, for helping us tell the story
Thank you. Any Questions?