In the last few years energy efficiency of large scale infrastructures gained a lot of attention, as power consumption became one of the most impacting factors of the operative costs of a data-center and of its Total Cost of Ownership. Power consumption can be observed at different layers of the data-center: from the overall power grid, moving to each rack and arriving to each machine and system. Given the rise of application containers in the cloud computing scenario, it becomes more and more important to measure power consumption also at the application level, where power-aware schedulers and orchestrators can optimize the execution of the workloads not only from a performance perspective, but also considering performance/power trade-offs. DEEP-mon is a novel monitoring tool able to measure power consumption and attribute it for each thread and application container running in the system, without any previous knowledge regarding the characteristics of the application and without any kind of workload instrumentation. DEEP-mon is able to aggregate data for threads, application containers and hosts with a negligible impact on the monitored system and on the running workloads. Information obtained with DEEP-mon open the way for a wide set of applications exploiting the capabilities offered by the monitoring tool, from power (and hence cost) metering of new software components deployed in the data center, to fine grained power capping and power-aware scheduling and co-location.

1. DEEP-mon: Dynamic and Energy Efficient Power
monitoring for container-based infrastructures
NECST Group Conference 2018 @ Facebook
06/01/2018
Rolando Brondolin, Tommaso Sardelli, Marco D. Santambrogio
<rolando.brondolin@polimi.it>

2. DEEP-mon at a glance
2
• DEEP-mon is a HT-aware fine-grain power monitor for container-based
environments
- precise power a5ribu8on to containers
- instrumenta8on free, watch workloads from outside
- lightweight, with liSle overhead on the target workloads and systems
- scalable and distributed, to observe Kubernetes clusters
• Monitoring ingredients:
Container
execution
Resource
usage
Power
consumption
Context
switch
Performance
Counter (cycle)*
Intel
RAPL
* cycles has 99% correlation w.r.t. CPU power usage

3. Anatomy of a power monitoring agent
3
user-space
kernel-space
Intel RAPL
DEEP-mon
Power attribution
Docker and Kubernetes metrics
kernel tracing
PMC
context switch
Linux CFS
Monitoring back-end

4. Anatomy of a power monitoring agent
4
user-space
kernel-space
Intel RAPL
DEEP-mon
Power attribution
Docker and Kubernetes metrics
PMC
Monitoring back-end
200K evts/s
kernel tracing context switch
Linux CFS

5. Kernel level data acquisi[on (1)
• We cannot send each context switch to user-space
- too many events per second to process
- too much overhead
• Introduce in-kernel data aggrega[on:
5
eBPF and BCC:
build, inject and execute code
in a Kernel VM
trace context switch,
count PMCs on the fly
store data in
eBPF data structures
send one big event instead
of many small ones
DEEP-mon
kernel

6. Kernel level data acquisi[on (2)
6
eBPF is event based, we leverage context switch to trigger PMC measures
eBPF output
HT1 HT2
t1
t2
t3
t4
Example: 2 threads running on 2 HT cores
store cycles (thread + core) data
store cycles (thread + core) data
account cycles (alone + overlap) to thread1
account cycles (alone + overlap) to thread2
HT1 data
HT2 data
processor map
HT1 data
Thread1
Thread2
Thread3
thread mapaccount overlap cycles for thread2
DEEP-mon
kernel
Thread execution overlap:
Power consumption of T1 + T2 is 1.1 w.r.t. T1+idle

7. Correlate power and performance
• At fixed [me intervals we collect the thread map
- extrac[on [me depends on # of context switch
• Then we extract power measurement from RAPL and we
account it for each thread:
7
eBPF output
Thread1
Thread2
Thread3
thread map
G benchmarks from NPB with
HT experiments pin two threads
ysical core
run on a Dell PowerEdge
n E5-2680 v2 (10 cores
and with Ubuntu Linux
st experiment shows that
cal cores mapped on the
umption is ' 1.15 with
g on that same physical
execution periods in which the thread was co-running on the
same physical core via HT, weighted by the HTr ratio and
divided by 2 to equally divide the overlapping cycles among
the two threads. In this context an execution period is defined
as the time between context switches on the physical core
where the thread is scheduled.
Starting from Equation (1), we can now attribute the power
measured by RAPL for our thread T1 following Equation (2),
where |K| is the cardinality of the set K of threads running in
the server in a given period of time and |S| is the cardinality
of the set S of sockets in the system.
PT 1(t) =
|S|
X
s=0
RAPLcore(t, s) ·
CyclesT W1 (t, s)
P|K|
k=0 CyclesT Wk
(t, s)
!
(2)
Starting from this result, the next sections will provide
details on how we implemented power attribution for each
thread and container running in the system.
B. Kernel level data acquisition
The power attribution model described in Section III-A
needs a precise measurement of the performance counter
Power of Thread 1
Sum among all sockets
RAPL measurement of the socket
Thread weight inside
the socket power consumption
• Finally we group each thread by container
DEEP-mon
kernel

8. Monitoring containers at scale
• Once power data is collected, we can send it to a back-end
on a regular basis
- further aggrega[on of metrics data
- Kubernetes cluster level view
• Backend exposes data for visualiza8on and autonomic power management
8

9. Benchmarks
Cloud Benchmarks: Phoronix test suite pts/apache, pts/Nginx, pts/fio
HPC Benchmarks: NAS Parallel benchmarks EP, MG, CG
Experimental results
9
Network and syscall intensive benchmarks CPU and memory intensive tasks
Cloud benchmarks
app overhead
< 3.3%
HPC benchmarks
app overhead
< 4%
Cloud benchmarks
power overhead
1.74% avg
HPC benchmarks
power overhead
0.90% avg
Evalua8on goals
Monitoring should introduce minimum overhead
We evaluated DEEP-mon w.r.t. its overhead on applica8ons and the target system

10. Conclusion
• We saw the main aspects of power monitoring for Docker containers
- fine grain and accurate monitoring
- low overhead power measurement
• Dynamic and Energy Efficient Power monitor (DEEP-mon)
- kernel-level performance data aggrega[on
- per thread power aSribu[on
- container aggrega[on
- Kubernetes cluster power visibility
10

11. Thanks for your aSen[on
11
NECST Group Conference 2018 @ Facebook
06/01/2018
Rolando Brondolin, Tommaso Sardelli, Marco D. Santambrogio
<rolando.brondolin@polimi.it>
DEEP-mon: Dynamic and Energy Efficient Power
monitoring for container-based infrastructures