mirror of
https://github.com/eunomia-bpf/bpf-developer-tutorial.git
synced 2026-02-03 02:04:30 +08:00
add energe
This commit is contained in:
victoryang00
3
src/48-energy/.gitignore
vendored
3
src/48-energy/.gitignore
vendored
@@ -20,6 +20,9 @@ package.json
|
||||
package.yaml
|
||||
ecli
|
||||
bootstrap
|
||||
energy_monitor
|
||||
.output/
|
||||
*.skel.h
|
||||
|
||||
# IDE
|
||||
.vscode/
|
||||
|
||||
@@ -24,7 +24,7 @@ INCLUDES := -I$(OUTPUT) -I../third_party/libbpf/include/uapi -I$(dir $(VMLINUX))
|
||||
CFLAGS := -g -Wall
|
||||
ALL_LDFLAGS := $(LDFLAGS) $(EXTRA_LDFLAGS)
|
||||
|
||||
APPS = bootstrap # minimal minimal_legacy uprobe kprobe fentry usdt sockfilter tc ksyscall
|
||||
APPS = energy_monitor # minimal minimal_legacy uprobe kprobe fentry usdt sockfilter tc ksyscall
|
||||
|
||||
CARGO ?= $(shell which cargo)
|
||||
ifeq ($(strip $(CARGO)),)
|
||||
|
||||
@@ -1,73 +1,601 @@
|
||||
# System Energy Monitoring with Intel RAPL
|
||||
# eBPF Tutorial: Energy Monitoring for Process-Level Power Analysis
|
||||
|
||||
This project provides tools to monitor system energy consumption using Intel's Running Average Power Limit (RAPL) interface.
|
||||
Have you ever wondered how much energy your applications are consuming? As energy efficiency becomes increasingly critical in both data centers and edge devices, understanding power consumption at the process level is essential for optimization. In this tutorial, we'll build an eBPF-based energy monitoring tool that provides real-time insights into process-level power consumption with minimal overhead.
|
||||
|
||||
## Features
|
||||
## Introduction to Energy Monitoring and Power Analysis
|
||||
|
||||
- Real-time power consumption monitoring
|
||||
- Live terminal-based display of power usage across different domains (CPU, DRAM, etc.)
|
||||
- Data logging to CSV or JSON formats
|
||||
- Support for multiple Intel RAPL domains
|
||||
- No external dependencies - uses only Python standard library
|
||||
Energy monitoring in computing systems has traditionally been challenging due to the lack of fine-grained measurement capabilities. While hardware counters like Intel RAPL (Running Average Power Limit) can measure total system or CPU package power, they don't tell you which processes are consuming that power. This is where software-based energy attribution comes into play.
|
||||
|
||||
## Requirements
|
||||
When a process runs on a CPU, it consumes power proportional to its CPU time and the processor's power state. The challenge is accurately tracking this relationship in real-time without introducing significant overhead that would itself consume power and skew measurements. Traditional approaches using polling-based monitoring can miss short-lived processes and introduce measurement overhead that affects the very metrics being measured.
|
||||
|
||||
- Intel CPU with RAPL support
|
||||
- Python 3.6+
|
||||
- Root access or appropriate permissions for `/sys/class/powercap/intel-rapl`
|
||||
This is where eBPF shines! By hooking into the kernel's scheduler events, we can track process CPU time with nanosecond precision at every context switch. This gives us:
|
||||
|
||||
## Installation
|
||||
- Exact CPU time measurements for every process
|
||||
- Zero sampling error for short-lived processes
|
||||
- Minimal overhead compared to polling approaches
|
||||
- Real-time energy attribution based on CPU time
|
||||
- The ability to correlate energy usage with specific workloads
|
||||
|
||||
No additional Python packages required - uses only Python standard library.
|
||||
## Understanding CPU Power Consumption
|
||||
|
||||
## Usage
|
||||
Before diving into the implementation, it's important to understand how CPU power consumption works. Modern processors consume power in several ways:
|
||||
|
||||
### Real-time Monitoring
|
||||
### Dynamic Power Consumption
|
||||
|
||||
Dynamic power is consumed when transistors switch states during computation. It's proportional to:
|
||||
- Frequency: Higher clock speeds mean more switching per second
|
||||
- Voltage: Higher voltages require more energy per switch
|
||||
- Activity: More instructions executed means more transistor switching
|
||||
|
||||
The relationship is approximately: P_dynamic = C × V² × f × α
|
||||
|
||||
Where C is capacitance, V is voltage, f is frequency, and α is the activity factor.
|
||||
|
||||
### Static Power Consumption
|
||||
|
||||
Static (or leakage) power is consumed even when transistors aren't switching, due to current leakage through the transistors. This has become increasingly significant in modern processors with billions of transistors.
|
||||
|
||||
### Power States and DVFS
|
||||
|
||||
Modern CPUs use Dynamic Voltage and Frequency Scaling (DVFS) to balance performance and power consumption. The processor can operate at different P-states (performance states) with varying frequency/voltage combinations, and enter C-states (idle states) when not actively computing.
|
||||
|
||||
Our energy monitoring approach estimates energy consumption by multiplying CPU time by average power consumption. While this is a simplification (it doesn't account for frequency changes or idle states), it provides a useful approximation for comparing relative energy usage between processes.
|
||||
|
||||
## Comparing Traditional vs eBPF Energy Monitoring
|
||||
|
||||
To understand why eBPF is superior for energy monitoring, let's compare it with traditional approaches:
|
||||
|
||||
### Traditional /proc-based Monitoring
|
||||
|
||||
Traditional energy monitoring tools typically work by periodically reading `/proc/stat` to sample CPU usage. Here's how our traditional monitor works:
|
||||
|
||||
```bash
|
||||
sudo python3 energy_monitor.py
|
||||
# Read total CPU time for a process
|
||||
cpu_time=$(awk '{print $14 + $15}' /proc/$pid/stat)
|
||||
|
||||
# Calculate energy based on time delta
|
||||
energy = cpu_power * (current_time - previous_time)
|
||||
```
|
||||
|
||||
This displays real-time power consumption in the terminal:
|
||||
- Power consumption for each domain (Package, DRAM, etc.)
|
||||
- Total system power consumption
|
||||
- Updates every 0.5 seconds
|
||||
This approach has several limitations:
|
||||
|
||||
### Logging Energy Data
|
||||
1. **Sampling Error**: Processes that start and stop between samples are missed entirely
|
||||
2. **Fixed Overhead**: Each sample requires reading and parsing `/proc` files
|
||||
3. **Limited Precision**: Typical sampling intervals are 100ms or more
|
||||
4. **Scalability Issues**: Monitoring many processes requires reading many files
|
||||
|
||||
### eBPF-based Monitoring
|
||||
|
||||
Our eBPF approach hooks directly into the kernel scheduler:
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_switch")
|
||||
int monitor_energy(struct trace_event_raw_sched_switch *ctx) {
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
// Track exact time when process stops running
|
||||
u64 delta = ts - previous_timestamp;
|
||||
update_runtime(prev_pid, delta);
|
||||
}
|
||||
```
|
||||
|
||||
The advantages are significant:
|
||||
|
||||
1. **Perfect Accuracy**: Every context switch is captured
|
||||
2. **Minimal Overhead**: No polling or file parsing needed
|
||||
3. **Nanosecond Precision**: Exact CPU time measurements
|
||||
4. **Scalable**: Same overhead whether monitoring 1 or 1000 processes
|
||||
|
||||
## Why eBPF for Energy Monitoring?
|
||||
|
||||
The landscape of energy monitoring has evolved significantly, as detailed in the comprehensive survey of eBPF energy projects. Let me incorporate the key insights from the energy monitoring ecosystem:
|
||||
|
||||
### Current State of eBPF Energy Projects
|
||||
|
||||
The eBPF ecosystem for energy management is rapidly evolving across two main categories: mature telemetry solutions and emerging power control frameworks.
|
||||
|
||||
**Energy Telemetry and Accounting (Production-Ready)**
|
||||
|
||||
| Project | Capabilities | Implementation Approach | Status |
|
||||
|---------|-------------|------------------------|---------|
|
||||
| **Kepler** | Container/pod energy attribution for Kubernetes | eBPF tracepoints + RAPL + performance counters | CNCF sandbox project, production deployments |
|
||||
| **Wattmeter** | Per-process energy tracking | Context-switch eBPF programs reading RAPL MSRs | Research prototype (HotCarbon '24), <1μs overhead |
|
||||
| **DEEP-mon** | Container power monitoring | In-kernel eBPF aggregation of scheduler events | Proven academic approach, avoids userspace overhead |
|
||||
|
||||
**Power Control via eBPF (Research and Development)**
|
||||
|
||||
The emerging power control landscape represents the next frontier in eBPF energy management. **cpufreq_ext** stands as the first upstream-bound eBPF implementation that can actually modify CPU frequency through a `bpf_struct_ops` interface, allowing frequency scaling policies to be written in eBPF rather than kernel C code.
|
||||
|
||||
Research prototypes include an **eBPF CPU-Idle Governor** that replaces traditional menu/TEO governors with eBPF hooks for dynamic idle state selection and idle injection. The conceptual **BEAR (BPF Energy-Aware Runtime)** framework aims to unify DVFS, idle, and thermal management under a single eBPF-based policy engine, though no public implementation exists yet.
|
||||
|
||||
### Why Our Approach Matters
|
||||
|
||||
Our energy monitor fits into the telemetry category but with a unique focus on educational clarity and comparison with traditional methods. eBPF's **event-driven architecture** fundamentally differs from polling-based approaches by reacting to kernel events in real-time. When the scheduler switches processes, our code runs immediately, capturing the exact transition moment with nanosecond precision.
|
||||
|
||||
The **in-kernel aggregation** capability eliminates the overhead of sending every context switch event to userspace by maintaining per-CPU hash maps in the kernel. Only aggregated data or sampled events need to cross the kernel-user boundary, dramatically reducing monitoring overhead. Combined with eBPF's **safety guarantees** through program verification before loading, this creates a production-ready solution that can't crash the kernel or create infinite loops.
|
||||
|
||||
Perhaps most importantly, eBPF enables **hot-pluggable analysis** where you can attach and detach the energy monitor without restarting applications or rebooting the system. This capability enables ad-hoc analysis of production workloads, something impossible with traditional kernel modules or instrumentation approaches.
|
||||
|
||||
### Real-World Impact
|
||||
|
||||
The practical benefits of eBPF energy monitoring are substantial across different deployment scenarios:
|
||||
|
||||
| Use Case | Traditional Approach | eBPF Approach | Benefit |
|
||||
|----------|---------------------|---------------|---------|
|
||||
| **Short-lived processes** | Often missed entirely | Every microsecond tracked | 100% visibility |
|
||||
| **Container monitoring** | High overhead per container | Shared kernel infrastructure | 10-100x less overhead |
|
||||
| **Production systems** | Risky kernel modules | Verified safe programs | Zero crash risk |
|
||||
| **Dynamic workloads** | Fixed sampling misses spikes | Event-driven captures all | Accurate spike detection |
|
||||
|
||||
### When eBPF Energy Monitoring is Essential
|
||||
|
||||
eBPF energy monitoring becomes critical in scenarios where precision, low overhead, and real-time feedback are paramount.
|
||||
|
||||
| Deployment Scenario | Key Requirements | Why eBPF Excels |
|
||||
|-------------------|------------------|-----------------|
|
||||
| **Battery-Powered Devices** | Every millijoule matters, minimal monitoring overhead | Low overhead means monitoring doesn't impact battery life |
|
||||
| **Multi-Tenant Clouds** | Accurate billing, power budget enforcement | Precise attribution enables fair energy accounting |
|
||||
| **Thermal Management** | Real-time feedback in thermally constrained environments | Event-driven updates provide immediate thermal response |
|
||||
| **Sustainability Reporting** | Audit-quality measurements for carbon footprint | Production-grade accuracy without traditional overhead |
|
||||
| **Performance/Watt Optimization** | Measure impact of code changes with minimal perturbation | A/B testing capabilities with near-zero measurement bias |
|
||||
|
||||
These use cases share common requirements that traditional polling-based approaches struggle to meet: the need for accurate, low-overhead, real-time energy attribution that can operate reliably in production environments.
|
||||
|
||||
The ecosystem is rapidly maturing, with projects like Kepler already deployed in production Kubernetes clusters and cpufreq_ext heading toward mainline kernel inclusion. Our tutorial provides a foundation for understanding and building upon these advanced capabilities.
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
Our energy monitoring solution provides a comprehensive comparison framework with two distinct implementations. The **eBPF Energy Monitor** delivers high-performance monitoring through kernel hooks, while the **Traditional Energy Monitor** uses bash-based `/proc` sampling to represent conventional approaches. A **Comparison Script** enables direct evaluation of both methods under identical conditions.
|
||||
|
||||
The eBPF implementation architecture consists of three tightly integrated components:
|
||||
|
||||
### Header File (energy_monitor.h)
|
||||
|
||||
Defines the shared data structure for kernel-user communication:
|
||||
|
||||
```c
|
||||
struct energy_event {
|
||||
__u64 ts; // Timestamp of context switch
|
||||
__u32 cpu; // CPU core where process ran
|
||||
__u32 pid; // Process ID
|
||||
__u64 runtime_ns; // How long process ran (nanoseconds)
|
||||
char comm[16]; // Process name
|
||||
};
|
||||
```
|
||||
|
||||
### eBPF Program (energy_monitor.bpf.c)
|
||||
|
||||
Implements the kernel-side logic with three key maps:
|
||||
|
||||
```c
|
||||
// Track when each process started running
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32); // PID
|
||||
__type(value, u64); // Start timestamp
|
||||
} time_lookup SEC(".maps");
|
||||
|
||||
// Accumulate total runtime per process
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32); // PID
|
||||
__type(value, u64); // Total runtime in microseconds
|
||||
} runtime_lookup SEC(".maps");
|
||||
|
||||
// Send events to userspace
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_RINGBUF);
|
||||
__uint(max_entries, 256 * 1024);
|
||||
} rb SEC(".maps");
|
||||
```
|
||||
|
||||
### User-Space Application (energy_monitor.c)
|
||||
|
||||
Processes events and calculates energy consumption based on configured CPU power.
|
||||
|
||||
## Implementation Deep Dive
|
||||
|
||||
Let's explore the key parts of our eBPF energy monitor implementation:
|
||||
|
||||
### Hooking into the Scheduler
|
||||
|
||||
The core of our monitor is the scheduler tracepoint that fires on every context switch:
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_switch")
|
||||
int monitor_energy(struct trace_event_raw_sched_switch *ctx)
|
||||
{
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
u32 cpu = bpf_get_smp_processor_id();
|
||||
|
||||
u32 prev_pid = ctx->prev_pid;
|
||||
u32 next_pid = ctx->next_pid;
|
||||
|
||||
// Calculate runtime for the process that just stopped
|
||||
u64 *old_ts_ptr = bpf_map_lookup_elem(&time_lookup, &prev_pid);
|
||||
if (old_ts_ptr) {
|
||||
u64 delta = ts - *old_ts_ptr;
|
||||
update_runtime(prev_pid, delta);
|
||||
|
||||
// Send event to userspace for real-time monitoring
|
||||
struct energy_event *e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
|
||||
if (e) {
|
||||
e->ts = ts;
|
||||
e->cpu = cpu;
|
||||
e->pid = prev_pid;
|
||||
e->runtime_ns = delta;
|
||||
bpf_probe_read_kernel_str(e->comm, sizeof(e->comm), ctx->prev_comm);
|
||||
bpf_ringbuf_submit(e, 0);
|
||||
}
|
||||
}
|
||||
|
||||
// Record when the next process starts running
|
||||
bpf_map_update_elem(&time_lookup, &next_pid, &ts, BPF_ANY);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
This function captures the exact moment when the CPU switches from one process to another, allowing us to calculate precisely how long each process ran.
|
||||
|
||||
### Efficient Time Calculation
|
||||
|
||||
To minimize overhead in the kernel, we use an optimized division function to convert nanoseconds to microseconds:
|
||||
|
||||
```c
|
||||
static inline u64 div_u64_by_1000(u64 n) {
|
||||
u64 q, r, t;
|
||||
t = (n >> 7) + (n >> 8) + (n >> 12);
|
||||
q = (n >> 1) + t + (n >> 15) + (t >> 11) + (t >> 14);
|
||||
q = q >> 9;
|
||||
r = n - q * 1000;
|
||||
return q + ((r + 24) >> 10);
|
||||
}
|
||||
```
|
||||
|
||||
This bit-shifting approach is much faster than regular division in the kernel context where floating-point operations aren't available.
|
||||
|
||||
### Energy Calculation in Userspace
|
||||
|
||||
The userspace program receives runtime events and calculates energy consumption:
|
||||
|
||||
```c
|
||||
static int handle_event(void *ctx, void *data, size_t data_sz)
|
||||
{
|
||||
const struct energy_event *e = data;
|
||||
|
||||
// Calculate energy in nanojoules
|
||||
// Energy (J) = Power (W) × Time (s)
|
||||
// Energy (nJ) = Power (W) × Time (ns)
|
||||
__u64 energy_nj = (__u64)(env.cpu_power_watts * e->runtime_ns);
|
||||
|
||||
if (env.verbose) {
|
||||
printf("%-16s pid=%-6d cpu=%-2d runtime=%llu ns energy=%llu nJ\n",
|
||||
e->comm, e->pid, e->cpu, e->runtime_ns, energy_nj);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
### Final Statistics
|
||||
|
||||
When the monitoring session ends, we aggregate the data from all CPU cores:
|
||||
|
||||
```c
|
||||
static void print_stats(struct energy_monitor_bpf *skel)
|
||||
{
|
||||
int num_cpus = libbpf_num_possible_cpus();
|
||||
__u64 *values = calloc(num_cpus, sizeof(__u64));
|
||||
|
||||
// Iterate through all processes
|
||||
while (bpf_map_get_next_key(bpf_map__fd(skel->maps.runtime_lookup),
|
||||
&key, &next_key) == 0) {
|
||||
// Sum values from all CPUs (percpu map)
|
||||
if (bpf_map_lookup_elem(bpf_map__fd(skel->maps.runtime_lookup),
|
||||
&next_key, values) == 0) {
|
||||
for (int i = 0; i < num_cpus; i++) {
|
||||
runtime_us += values[i];
|
||||
}
|
||||
|
||||
// Calculate energy
|
||||
double energy_mj = (env.cpu_power_watts * runtime_us) / 1000000.0;
|
||||
printf("%-10d %-16s %-15.2f %-15.4f\n",
|
||||
next_key, comm, runtime_ms, energy_mj);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Building and Running the Energy Monitor
|
||||
|
||||
### Prerequisites
|
||||
|
||||
Before building, ensure you have:
|
||||
- Linux kernel 5.4 or newer with BTF support
|
||||
- libbpf development files
|
||||
- clang and llvm for eBPF compilation
|
||||
- Basic build tools (make, gcc)
|
||||
|
||||
### Compilation
|
||||
|
||||
Build all components with the provided Makefile:
|
||||
|
||||
```bash
|
||||
sudo python3 energy_monitor.py -l -d 300 -i 0.5 -f csv -o my_energy_log
|
||||
cd /yunwei37/bpf-developer-tutorial/src/48-energy
|
||||
make clean && make
|
||||
```
|
||||
|
||||
Options:
|
||||
- `-d, --duration`: Monitoring duration in seconds (default: 60)
|
||||
- `-i, --interval`: Sampling interval in seconds (default: 1.0)
|
||||
- `-f, --format`: Output format - csv or json (default: csv)
|
||||
- `-o, --output`: Output filename without extension
|
||||
This creates:
|
||||
- `energy_monitor`: The eBPF-based energy monitor
|
||||
- `energy_monitor_traditional.sh`: The traditional polling-based monitor
|
||||
- `compare_monitors.sh`: Script to compare both approaches
|
||||
|
||||
## Permissions
|
||||
### Running the eBPF Monitor
|
||||
|
||||
If you don't want to run with sudo, adjust permissions:
|
||||
The eBPF monitor requires root privileges to attach to kernel tracepoints:
|
||||
|
||||
```bash
|
||||
sudo chmod -R a+r /sys/class/powercap/intel-rapl
|
||||
# Monitor all processes for 10 seconds with 15W CPU power
|
||||
sudo ./energy_monitor -d 10 -p 15.0
|
||||
|
||||
# Monitor with verbose output
|
||||
sudo ./energy_monitor -v -d 10
|
||||
|
||||
# Continuous monitoring (Ctrl+C to stop)
|
||||
sudo ./energy_monitor
|
||||
```
|
||||
|
||||
Note: This allows all users to read RAPL data but not modify power limits.
|
||||
Example output:
|
||||
|
||||
## RAPL Domains
|
||||
|
||||
Common domains include:
|
||||
- `package-0`: Entire CPU package power
|
||||
- `core`: CPU cores power
|
||||
- `uncore`: CPU uncore components (cache, memory controller)
|
||||
- `dram`: Memory power consumption
|
||||
|
||||
## Example Output
|
||||
|
||||
The logger provides a summary like:
|
||||
```
|
||||
Total samples: 300
|
||||
Average power: 45.23 W
|
||||
Total energy: 0.0377 Wh
|
||||
```
|
||||
Energy monitor started... Hit Ctrl-C to end.
|
||||
CPU Power: 15.00 W
|
||||
Running for 10 seconds
|
||||
|
||||
=== Energy Usage Summary ===
|
||||
PID COMM Runtime (ms) Energy (mJ)
|
||||
---------- ---------------- --------------- ---------------
|
||||
39716 firefox 541.73 8.1260
|
||||
19845 node 67.71 1.0157
|
||||
39719 vscode 63.15 0.9472
|
||||
29712 chrome 13.34 0.2000
|
||||
...
|
||||
|
||||
Total CPU time: 2781.52 ms
|
||||
Total estimated energy: 0.0417 J (41.7229 mJ)
|
||||
CPU power setting: 15.00 W
|
||||
```
|
||||
|
||||
### Running the Traditional Monitor
|
||||
|
||||
The traditional monitor uses `/proc` sampling and runs without special privileges:
|
||||
|
||||
```bash
|
||||
# Monitor for 10 seconds with verbose output
|
||||
./energy_monitor_traditional.sh -d 10 -v
|
||||
|
||||
# Adjust sampling interval (default 100ms)
|
||||
./energy_monitor_traditional.sh -d 10 -i 0.05
|
||||
```
|
||||
|
||||
### Comparing Both Approaches
|
||||
|
||||
Use the comparison script to see the differences:
|
||||
|
||||
```bash
|
||||
# Basic comparison
|
||||
sudo ./compare_monitors.sh -d 10
|
||||
|
||||
# With a CPU workload
|
||||
sudo ./compare_monitors.sh -d 10 -w "stress --cpu 2 --timeout 10"
|
||||
```
|
||||
|
||||
Example comparison output:
|
||||
|
||||
```
|
||||
Comparison Results
|
||||
==================
|
||||
|
||||
Metric Traditional eBPF
|
||||
------------------------- --------------- ---------------
|
||||
Total Energy (J) 1.050000 0.0288
|
||||
Monitoring Time (s) 5.112031 4.500215
|
||||
Samples/Events 50 Continuous
|
||||
|
||||
Performance Analysis:
|
||||
- Traditional monitoring overhead: 13.00% compared to eBPF
|
||||
- eBPF provides per-context-switch granularity
|
||||
- Traditional samples at fixed intervals (100ms)
|
||||
```
|
||||
|
||||
## Understanding Energy Monitoring Trade-offs
|
||||
|
||||
While our energy monitor provides valuable insights, it's important to understand its limitations and trade-offs:
|
||||
|
||||
### Accuracy Considerations
|
||||
|
||||
Our energy monitoring model employs a simplified approach using the formula: Energy = CPU_Power × CPU_Time. While this provides valuable comparative insights, it doesn't account for several dynamic factors that affect real power consumption.
|
||||
|
||||
**Frequency scaling** represents a significant limitation as modern CPUs change frequency dynamically based on workload and thermal conditions. Different **idle states** (C-states) also consume varying amounts of power, from near-zero in deep sleep to significant standby power in shallow idle states. Additionally, **workload characteristics** matter because some instructions (particularly vector operations and memory-intensive tasks) consume more power per cycle than simple arithmetic operations.
|
||||
|
||||
The model also overlooks **shared resource consumption** from cache, memory controllers, and I/O subsystems that contribute to total system power but aren't directly attributable to CPU execution time.
|
||||
|
||||
For production deployments requiring higher accuracy, enhancements would include reading hardware performance counters for actual power measurements, tracking frequency changes through DVFS events, modeling different instruction types based on performance counters, and incorporating memory and I/O activity metrics from the broader system.
|
||||
|
||||
### When to Use Each Approach
|
||||
|
||||
The choice between eBPF and traditional monitoring depends on your specific requirements and constraints.
|
||||
|
||||
**eBPF monitoring** excels when you need accurate CPU time tracking, particularly for short-lived processes that traditional sampling might miss entirely. Its minimal measurement overhead makes it ideal for production environments where the monitoring tool itself shouldn't impact the workload being measured. eBPF is particularly valuable for comparative analysis between processes, where relative accuracy matters more than absolute precision.
|
||||
|
||||
**Traditional monitoring** remains appropriate when eBPF isn't available due to permission restrictions or older kernel versions lacking BTF support. It provides a simple, portable solution that requires no special privileges and works across different platforms. For monitoring long-running, stable workloads where approximate measurements are sufficient, traditional approaches offer adequate insight with simpler deployment requirements.
|
||||
|
||||
## Practical Use Cases and Deployment Scenarios
|
||||
|
||||
Understanding when and how to deploy eBPF energy monitoring helps maximize its value. Here are real-world scenarios where it excels:
|
||||
|
||||
### Data Center Energy Optimization
|
||||
|
||||
Modern data centers operate under strict power budgets and cooling constraints where eBPF energy monitoring provides critical operational capabilities. **Workload placement** becomes intelligent when schedulers understand the energy profile of different applications, enabling balanced power consumption across racks while avoiding thermal hot spots and maximizing overall efficiency.
|
||||
|
||||
During peak demand periods, **power capping** systems can leverage real-time energy attribution to identify and selectively throttle the most power-hungry processes without impacting critical services. This surgical approach maintains service levels while staying within power infrastructure limits.
|
||||
|
||||
For cloud providers, **billing and chargeback** accuracy drives customer behavior toward more efficient code. When customers can see the actual energy cost of their workloads, they have direct financial incentives to optimize their applications for energy efficiency.
|
||||
|
||||
### Mobile and Edge Computing
|
||||
|
||||
Battery-powered devices present unique energy constraints where precise monitoring becomes essential for user experience and device longevity. **App energy profiling** empowers developers with exact energy consumption data during different operations, enabling targeted optimizations that can significantly extend battery life without sacrificing functionality.
|
||||
|
||||
Operating systems benefit from **background task management** intelligence, where historical energy consumption patterns inform decisions about which background tasks to allow or defer. This prevents energy-hungry background processes from draining batteries while maintaining essential services.
|
||||
|
||||
In devices without active cooling, **thermal management** becomes critical as energy monitoring helps predict thermal buildup before throttling occurs. By understanding energy patterns, the system can proactively manage workloads to maintain consistent performance within thermal limits.
|
||||
|
||||
### Development and CI/CD Integration
|
||||
|
||||
Integrating energy monitoring into development workflows creates a continuous feedback loop that prevents efficiency regressions from reaching production. **Energy regression testing** becomes automated through CI/CD pipelines that flag code changes increasing energy consumption beyond predefined thresholds, treating energy efficiency as a first-class software quality metric.
|
||||
|
||||
**Performance/watt optimization** provides developers with visibility into the true cost of performance improvements. Some optimizations may increase speed while dramatically increasing energy consumption, and others may achieve better efficiency with minimal performance impact. This visibility enables informed architectural decisions that balance speed and efficiency based on actual workload requirements.
|
||||
|
||||
**Green software metrics** integration allows organizations to track and report energy efficiency as part of sustainability initiatives. Regular measurement provides concrete data for environmental impact reporting while creating accountability for software teams to consider energy efficiency in their development practices.
|
||||
|
||||
### Research and Education
|
||||
|
||||
eBPF energy monitoring serves as a powerful research and educational tool that bridges the gap between theoretical understanding and practical system behavior. **Algorithm comparison** becomes rigorous when researchers can measure energy efficiency differences between approaches under production-realistic conditions, providing empirical data that complements theoretical complexity analysis.
|
||||
|
||||
**System behavior analysis** reveals complex interactions between different components from an energy perspective, uncovering optimization opportunities that aren't apparent when looking at performance metrics alone. These insights drive system design decisions that consider the total cost of ownership, including operational energy costs.
|
||||
|
||||
As a **teaching tool**, energy monitoring makes abstract concepts tangible by showing students the immediate energy impact of their code. When algorithmic complexity discussions are paired with real energy measurements, students develop intuition about the practical implications of their design choices beyond just computational efficiency.
|
||||
|
||||
## Extending the Energy Monitor
|
||||
|
||||
The current implementation provides a solid foundation for building more sophisticated energy monitoring capabilities. Several enhancement directions offer significant value for different deployment scenarios.
|
||||
|
||||
| Extension Area | Implementation Approach | Value Proposition |
|
||||
|---------------|------------------------|-------------------|
|
||||
| **Hardware Counter Integration** | Integrate RAPL counters via `PERF_TYPE_POWER` events | Replace estimation with actual hardware measurements |
|
||||
| **Per-Core Power Modeling** | Track core assignment and model P-core vs E-core differences | Accurate attribution on heterogeneous processors |
|
||||
| **Workload Classification** | Classify CPU-intensive, memory-bound, I/O-bound, and idle patterns | Enable workload-specific power optimization |
|
||||
| **Container Runtime Integration** | Aggregate energy by container/pod for Kubernetes environments | Cloud-native energy attribution and billing |
|
||||
| **Real-time Visualization** | Web dashboard with live energy consumption graphs | Immediate feedback for energy optimization |
|
||||
|
||||
**Hardware counter integration** represents the most impactful enhancement, replacing our simplified estimation model with actual hardware measurements through RAPL (Running Average Power Limit) interfaces. Modern processors provide detailed energy counters that can be read via performance events, offering precise energy measurements down to individual CPU packages.
|
||||
|
||||
```c
|
||||
// Read RAPL counters for actual energy measurements
|
||||
struct perf_event_attr attr = {
|
||||
.type = PERF_TYPE_POWER,
|
||||
.config = PERF_COUNT_HW_POWER_PKG,
|
||||
};
|
||||
```
|
||||
|
||||
**Per-core power modeling** becomes essential on heterogeneous processors where performance cores and efficiency cores have dramatically different power characteristics. Tracking which core each process runs on enables accurate energy attribution:
|
||||
|
||||
```c
|
||||
// Different cores may have different power characteristics
|
||||
double core_power[MAX_CPUS] = {15.0, 15.0, 10.0, 10.0}; // P-cores vs E-cores
|
||||
```
|
||||
|
||||
**Workload classification** enhances energy monitoring by recognizing different computational patterns and their associated energy costs:
|
||||
|
||||
```c
|
||||
enum workload_type {
|
||||
WORKLOAD_CPU_INTENSIVE,
|
||||
WORKLOAD_MEMORY_BOUND,
|
||||
WORKLOAD_IO_BOUND,
|
||||
WORKLOAD_IDLE
|
||||
};
|
||||
```
|
||||
|
||||
## Troubleshooting Common Issues
|
||||
|
||||
When deploying eBPF energy monitoring, you might encounter these common issues:
|
||||
|
||||
### Permission Denied
|
||||
|
||||
If you see permission errors when running the eBPF monitor:
|
||||
|
||||
```bash
|
||||
# Check if BPF is enabled
|
||||
sudo sysctl kernel.unprivileged_bpf_disabled
|
||||
|
||||
# Enable BPF for debugging (not recommended for production)
|
||||
sudo sysctl kernel.unprivileged_bpf_disabled=0
|
||||
```
|
||||
|
||||
### Missing BTF Information
|
||||
|
||||
If the kernel lacks BTF (BPF Type Format) data:
|
||||
|
||||
```bash
|
||||
# Check for BTF support
|
||||
ls /sys/kernel/btf/vmlinux
|
||||
|
||||
# On older kernels, you may need to generate BTF
|
||||
# or use a kernel with CONFIG_DEBUG_INFO_BTF=y
|
||||
```
|
||||
|
||||
### High CPU Usage
|
||||
|
||||
If the monitor itself causes high CPU usage:
|
||||
|
||||
1. Reduce the ring buffer size in the eBPF program
|
||||
2. Increase the batch size for reading events
|
||||
3. Filter events in the kernel to reduce volume
|
||||
|
||||
### Missing Processes
|
||||
|
||||
If some processes aren't being tracked:
|
||||
|
||||
1. Check if they're running in a different PID namespace
|
||||
2. Ensure the monitor starts before the processes
|
||||
3. Verify the hash map size is sufficient
|
||||
|
||||
## Future Directions
|
||||
|
||||
The field of eBPF-based energy monitoring is rapidly evolving. Here are exciting developments on the horizon:
|
||||
|
||||
### Integration with Hardware Accelerators
|
||||
|
||||
As GPUs, TPUs, and other accelerators become common, extending eBPF monitoring to track their energy consumption will provide complete system visibility.
|
||||
|
||||
### Machine Learning for Power Prediction
|
||||
|
||||
Using eBPF-collected data to train models that predict future power consumption based on workload patterns, enabling proactive power management.
|
||||
|
||||
### Standardization Efforts
|
||||
|
||||
Work is underway to standardize eBPF energy monitoring interfaces, making it easier to build portable tools that work across different platforms.
|
||||
|
||||
### Carbon-Aware Computing
|
||||
|
||||
Combining energy monitoring with real-time carbon intensity data to automatically shift workloads to times and locations with cleaner energy.
|
||||
|
||||
## References and Further Reading
|
||||
|
||||
To dive deeper into the topics covered in this tutorial:
|
||||
|
||||
### Energy and Power Management
|
||||
|
||||
- Intel Running Average Power Limit (RAPL): [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html)
|
||||
- Linux Power Management: [https://www.kernel.org/doc/html/latest/admin-guide/pm/index.html](https://www.kernel.org/doc/html/latest/admin-guide/pm/index.html)
|
||||
- ACPI Specification: [https://uefi.org/specifications](https://uefi.org/specifications)
|
||||
|
||||
### Related Projects
|
||||
|
||||
- Kepler (Kubernetes Efficient Power Level Exporter): [https://sustainable-computing.io/](https://sustainable-computing.io/)
|
||||
- Scaphandre Power Measurement: [https://github.com/hubblo-org/scaphandre](https://github.com/hubblo-org/scaphandre)
|
||||
- PowerTOP: [https://github.com/fenrus75/powertop](https://github.com/fenrus75/powertop)
|
||||
- cpufreq_ext eBPF Governor: [https://lwn.net/Articles/991991/](https://lwn.net/Articles/991991/)
|
||||
- Wattmeter (HotCarbon '24): [https://www.asafcidon.com/uploads/5/9/7/0/59701649/energy-aware-ebpf.pdf](https://www.asafcidon.com/uploads/5/9/7/0/59701649/energy-aware-ebpf.pdf)
|
||||
|
||||
### Academic Papers
|
||||
|
||||
- "Energy-Aware Process Scheduling in Linux" (HotCarbon '24)
|
||||
- "DEEP-mon: Dynamic and Energy Efficient Power monitoring for container-based infrastructures"
|
||||
- "eBPF-based Energy-Aware Scheduling" research papers
|
||||
|
||||
The complete code for this tutorial is available at: [https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/main/src/48-energy](https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/main/src/48-energy)
|
||||
|
||||
For more eBPF tutorials and projects, visit: [https://eunomia.dev/tutorials/](https://eunomia.dev/tutorials/)
|
||||
|
||||
536
src/48-energy/README_zh.md
Normal file
536
src/48-energy/README_zh.md
Normal file
@@ -0,0 +1,536 @@
|
||||
# eBPF 教程：进程级能源监控与功耗分析
|
||||
|
||||
您是否想过应用程序到底消耗了多少能源？在数据中心和边缘设备中，能源效率正变得愈发重要，深入了解进程级别的功耗已成为系统优化的关键。本教程将带您构建一个基于 eBPF 的能源监控工具，它能以极低的系统开销实时洞察进程的功耗情况。
|
||||
|
||||
## 能源监控和功耗分析简介
|
||||
|
||||
长期以来，计算系统的能源监控一直面临着细粒度测量能力不足的挑战。虽然 Intel RAPL（Running Average Power Limit）等硬件计数器能够测量系统总功耗或 CPU 封装功耗，但无法精确定位具体是哪些进程在消耗这些能量。这正是软件层面能源归因技术的用武之地。
|
||||
|
||||
进程在 CPU 上运行时，其功耗与 CPU 占用时间和处理器功率状态密切相关。难点在于如何实时精确地追踪这种关系，同时避免监控本身带来的额外功耗和测量偏差。传统的轮询式监控方法容易遗漏短生命周期的进程，而且监控开销会影响测量的准确性。
|
||||
|
||||
eBPF 技术的出现彻底改变了这一局面！通过在内核调度器事件上设置钩子，我们能够以纳秒级精度捕获每次上下文切换时的进程 CPU 时间。这种方法不仅能精确测量每个进程的 CPU 时间，完全消除短生命周期进程的采样误差，还能相比轮询方式大幅降低监控开销。更重要的是，它支持实时计算基于 CPU 时间的能源消耗，精准关联能源使用与具体工作负载。
|
||||
|
||||
## 理解 CPU 功耗
|
||||
|
||||
在深入实现之前，了解 CPU 功耗的工作原理非常重要。现代处理器以几种方式消耗功率：
|
||||
|
||||
### 动态功耗
|
||||
|
||||
动态功耗产生于晶体管状态切换的过程中。当处理器工作在更高的时钟频率时，单位时间内的状态切换次数增加；当电压升高时，每次切换消耗的能量也相应增大；而执行的指令越多，参与切换的晶体管数量就越多。这些因素共同决定了动态功耗的大小，其关系可以用公式表示为：P_dynamic = C × V² × f × α，其中 C 表示电容，V 表示电压，f 表示频率，α 表示活动因子。
|
||||
|
||||
### 静态功耗
|
||||
|
||||
即使晶体管不切换，由于通过晶体管的电流泄漏，也会消耗静态（或泄漏）功率。在拥有数十亿个晶体管的现代处理器中，这变得越来越重要。
|
||||
|
||||
### 功率状态和 DVFS
|
||||
|
||||
现代 CPU 使用动态电压和频率调节（DVFS）来平衡性能和功耗。处理器可以在具有不同频率/电压组合的不同 P 状态（性能状态）下运行，并在不主动计算时进入 C 状态（空闲状态）。
|
||||
|
||||
我们的能源监控方法通过将 CPU 时间乘以平均功耗来估算能源消耗。虽然这是一种简化（它不考虑频率变化或空闲状态），但它提供了一个有用的近似值来比较进程之间的相对能源使用。
|
||||
|
||||
## 比较传统与 eBPF 能源监控
|
||||
|
||||
为了理解为什么 eBPF 在能源监控方面更优越，让我们将其与传统方法进行比较：
|
||||
|
||||
### 传统的基于 /proc 的监控
|
||||
|
||||
传统的能源监控工具通常通过定期读取 `/proc/stat` 来采样 CPU 使用情况。以下是我们的传统监控器的工作原理：
|
||||
|
||||
```bash
|
||||
# 读取进程的总 CPU 时间
|
||||
cpu_time=$(awk '{print $14 + $15}' /proc/$pid/stat)
|
||||
|
||||
# 基于时间差计算能量
|
||||
energy = cpu_power * (current_time - previous_time)
|
||||
```
|
||||
|
||||
这种方法存在明显的局限性。首先是**采样误差**问题，在采样间隔内启动和停止的进程会被完全遗漏。其次是**固定开销**，每次采样都需要读取和解析 `/proc` 文件系统。再者是**精度限制**，典型的采样间隔达到 100ms 或更长。最后是**可扩展性**挑战，监控大量进程时需要频繁读取众多文件，开销急剧增加。
|
||||
|
||||
### 基于 eBPF 的监控
|
||||
|
||||
我们的 eBPF 方法直接挂钩到内核调度器：
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_switch")
|
||||
int monitor_energy(struct trace_event_raw_sched_switch *ctx) {
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
// 跟踪进程停止运行的确切时间
|
||||
u64 delta = ts - previous_timestamp;
|
||||
update_runtime(prev_pid, delta);
|
||||
}
|
||||
```
|
||||
|
||||
这种方法的优势非常明显。它能够捕获每一次上下文切换，实现**完美精度**；无需轮询或文件解析，保证了**最小开销**；提供**纳秒级精度**的 CPU 时间测量；更重要的是具有出色的**可扩展性**，无论监控 1 个还是 1000 个进程，系统开销基本相同。
|
||||
|
||||
## 为什么选择 eBPF 进行能源监控？
|
||||
|
||||
能源监控的格局已经显著发展，正如 eBPF 能源项目综合调查中详细描述的那样。让我结合能源监控生态系统的关键见解：
|
||||
|
||||
### eBPF 能源项目的当前状态
|
||||
|
||||
eBPF 能源管理生态系统正在两个主要类别中快速发展：成熟的遥测解决方案和新兴的功率控制框架。
|
||||
|
||||
**能源遥测和计费（生产就绪）**
|
||||
|
||||
在生产就绪的能源遥测和计费领域，已经涌现出几个成熟的解决方案。**Kepler** 作为 CNCF 沙箱项目，已经在生产环境中广泛部署，它专注于 Kubernetes 环境中的容器和 pod 能源归因，通过结合 eBPF 跟踪点、RAPL 硬件计数器和性能计数器来实现精确测量。**Wattmeter** 则是一个研究原型，在 HotCarbon '24 会议上展示，它通过在上下文切换时读取 RAPL MSR 寄存器的 eBPF 程序来实现每进程能源跟踪，其开销低于 1 微秒，展现了极高的效率。**DEEP-mon** 提供了另一种经过学术验证的方法，专门针对容器功率监控，通过在内核内对调度器事件进行 eBPF 聚合，巧妙地避免了用户空间的开销。
|
||||
|
||||
**通过 eBPF 进行功率控制（研发中）**
|
||||
|
||||
新兴的功率控制领域代表了 eBPF 能源管理的下一个前沿。**cpufreq_ext** 是第一个可以通过 `bpf_struct_ops` 接口实际修改 CPU 频率的上游 eBPF 实现，允许用 eBPF 而不是内核 C 代码编写频率调节策略。
|
||||
|
||||
研究原型包括一个 **eBPF CPU 空闲调节器**，它用 eBPF 挂钩替换传统的 menu/TEO 调节器，用于动态空闲状态选择和空闲注入。概念性的 **BEAR（BPF 能源感知运行时）** 框架旨在在单个基于 eBPF 的策略引擎下统一 DVFS、空闲和热管理，尽管还没有公开实现。
|
||||
|
||||
### 为什么我们的方法很重要
|
||||
|
||||
我们的能源监控器属于遥测类别，但特别关注教育清晰度和与传统方法的比较。eBPF 的**事件驱动架构**与基于轮询的方法根本不同，它实时响应内核事件。当调度器切换进程时，我们的代码立即运行，以纳秒精度捕获确切的转换时刻。
|
||||
|
||||
**内核内聚合**功能通过在内核中维护每个 CPU 的哈希映射，消除了将每个上下文切换事件发送到用户空间的开销。只有聚合数据或采样事件需要跨越内核-用户边界，大大减少了监控开销。结合 eBPF 在加载前通过程序验证的**安全保证**，这创建了一个生产就绪的解决方案，不会崩溃内核或创建无限循环。
|
||||
|
||||
也许最重要的是，eBPF 支持**热插拔分析**，您可以在不重新启动应用程序或重新启动系统的情况下附加和分离能源监控器。这种能力支持对生产工作负载进行临时分析，这是传统内核模块或检测方法无法做到的。
|
||||
|
||||
### 现实世界的影响
|
||||
|
||||
eBPF 能源监控在不同部署场景中展现出的实际优势令人瞩目。对于**短暂进程**，传统方法经常会完全错过这些快速启动和停止的进程，而 eBPF 方法能够跟踪每一微秒，实现 100% 的可见性。在**容器监控**场景中，传统方法需要为每个容器承担高昂的监控开销，而 eBPF 通过共享内核基础设施，能够将开销降低 10 到 100 倍。对于**生产系统**而言，传统的内核模块存在系统崩溃的风险，而 eBPF 的验证安全程序确保了零崩溃风险。面对**动态工作负载**时，传统的固定采样方式容易错过功耗峰值，而 eBPF 的事件驱动机制能够捕获所有变化，实现准确的峰值检测。
|
||||
|
||||
### 何时 eBPF 能源监控至关重要
|
||||
|
||||
eBPF 能源监控在多种关键场景中发挥着不可替代的作用。在**电池供电设备**上，每一毫焦耳的能量都至关重要，而 eBPF 的低开销特性确保了监控过程本身不会影响电池寿命。**多租户云**环境需要准确的能源计费和功率预算执行，eBPF 的精确归因能力使得公平的能源计费成为可能。在**热管理**场景中，热约束环境需要实时反馈，eBPF 的事件驱动更新机制能够提供即时的热响应。对于**可持续性报告**，组织需要审计级别的碳足迹测量，eBPF 提供了生产级的精度，同时避免了传统方法的高开销。在进行**性能/瓦特优化**时，开发者需要以最小的干扰测量代码更改的影响，eBPF 提供了接近零偏差的 A/B 测试能力。
|
||||
|
||||
这些用例共享传统基于轮询的方法难以满足的共同要求：需要准确、低开销、实时的能源归因，可以在生产环境中可靠运行。
|
||||
|
||||
生态系统正在迅速成熟，像 Kepler 这样的项目已经部署在生产 Kubernetes 集群中，cpufreq_ext 正朝着主线内核包含的方向发展。我们的教程为理解和构建这些高级功能提供了基础。
|
||||
|
||||
## 架构概述
|
||||
|
||||
我们的能源监控解决方案提供了一个全面的比较框架，包含两种不同的实现。**eBPF 能源监控器**通过内核挂钩提供高性能监控，而**传统能源监控器**使用基于 bash 的 `/proc` 采样来代表传统方法。**比较脚本**允许在相同条件下直接评估两种方法。
|
||||
|
||||
eBPF 实现架构由三个紧密集成的组件组成：
|
||||
|
||||
### 头文件 (energy_monitor.h)
|
||||
|
||||
定义内核-用户通信的共享数据结构：
|
||||
|
||||
```c
|
||||
struct energy_event {
|
||||
__u64 ts; // 上下文切换的时间戳
|
||||
__u32 cpu; // 进程运行的 CPU 核心
|
||||
__u32 pid; // 进程 ID
|
||||
__u64 runtime_ns; // 进程运行时间（纳秒）
|
||||
char comm[16]; // 进程名称
|
||||
};
|
||||
```
|
||||
|
||||
### eBPF 程序 (energy_monitor.bpf.c)
|
||||
|
||||
使用三个关键映射实现内核端逻辑：
|
||||
|
||||
```c
|
||||
// 跟踪每个进程开始运行的时间
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32); // PID
|
||||
__type(value, u64); // 开始时间戳
|
||||
} time_lookup SEC(".maps");
|
||||
|
||||
// 累积每个进程的总运行时间
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32); // PID
|
||||
__type(value, u64); // 总运行时间（微秒）
|
||||
} runtime_lookup SEC(".maps");
|
||||
|
||||
// 向用户空间发送事件
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_RINGBUF);
|
||||
__uint(max_entries, 256 * 1024);
|
||||
} rb SEC(".maps");
|
||||
```
|
||||
|
||||
### 用户空间应用程序 (energy_monitor.c)
|
||||
|
||||
处理事件并基于配置的 CPU 功率计算能源消耗。
|
||||
|
||||
## 实现深入探讨
|
||||
|
||||
让我们探索 eBPF 能源监控器实现的关键部分：
|
||||
|
||||
### 挂钩到调度器
|
||||
|
||||
我们监控器的核心是在每次上下文切换时触发的调度器跟踪点：
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_switch")
|
||||
int monitor_energy(struct trace_event_raw_sched_switch *ctx)
|
||||
{
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
u32 cpu = bpf_get_smp_processor_id();
|
||||
|
||||
u32 prev_pid = ctx->prev_pid;
|
||||
u32 next_pid = ctx->next_pid;
|
||||
|
||||
// 计算刚刚停止的进程的运行时间
|
||||
u64 *old_ts_ptr = bpf_map_lookup_elem(&time_lookup, &prev_pid);
|
||||
if (old_ts_ptr) {
|
||||
u64 delta = ts - *old_ts_ptr;
|
||||
update_runtime(prev_pid, delta);
|
||||
|
||||
// 向用户空间发送事件以进行实时监控
|
||||
struct energy_event *e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
|
||||
if (e) {
|
||||
e->ts = ts;
|
||||
e->cpu = cpu;
|
||||
e->pid = prev_pid;
|
||||
e->runtime_ns = delta;
|
||||
bpf_probe_read_kernel_str(e->comm, sizeof(e->comm), ctx->prev_comm);
|
||||
bpf_ringbuf_submit(e, 0);
|
||||
}
|
||||
}
|
||||
|
||||
// 记录下一个进程开始运行的时间
|
||||
bpf_map_update_elem(&time_lookup, &next_pid, &ts, BPF_ANY);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
这个函数捕获 CPU 从一个进程切换到另一个进程的确切时刻，使我们能够精确计算每个进程运行了多长时间。
|
||||
|
||||
### 高效的时间计算
|
||||
|
||||
为了最小化内核中的开销，我们使用优化的除法函数将纳秒转换为微秒：
|
||||
|
||||
```c
|
||||
static inline u64 div_u64_by_1000(u64 n) {
|
||||
u64 q, r, t;
|
||||
t = (n >> 7) + (n >> 8) + (n >> 12);
|
||||
q = (n >> 1) + t + (n >> 15) + (t >> 11) + (t >> 14);
|
||||
q = q >> 9;
|
||||
r = n - q * 1000;
|
||||
return q + ((r + 24) >> 10);
|
||||
}
|
||||
```
|
||||
|
||||
这种位移方法在内核上下文中比常规除法快得多，在内核上下文中浮点运算不可用。
|
||||
|
||||
### 用户空间中的能源计算
|
||||
|
||||
用户空间程序接收运行时事件并计算能源消耗：
|
||||
|
||||
```c
|
||||
static int handle_event(void *ctx, void *data, size_t data_sz)
|
||||
{
|
||||
const struct energy_event *e = data;
|
||||
|
||||
// 计算能量（纳焦耳）
|
||||
// 能量 (J) = 功率 (W) × 时间 (s)
|
||||
// 能量 (nJ) = 功率 (W) × 时间 (ns)
|
||||
__u64 energy_nj = (__u64)(env.cpu_power_watts * e->runtime_ns);
|
||||
|
||||
if (env.verbose) {
|
||||
printf("%-16s pid=%-6d cpu=%-2d runtime=%llu ns energy=%llu nJ\n",
|
||||
e->comm, e->pid, e->cpu, e->runtime_ns, energy_nj);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
### 最终统计
|
||||
|
||||
当监控会话结束时，我们聚合来自所有 CPU 核心的数据：
|
||||
|
||||
```c
|
||||
static void print_stats(struct energy_monitor_bpf *skel)
|
||||
{
|
||||
int num_cpus = libbpf_num_possible_cpus();
|
||||
__u64 *values = calloc(num_cpus, sizeof(__u64));
|
||||
|
||||
// 遍历所有进程
|
||||
while (bpf_map_get_next_key(bpf_map__fd(skel->maps.runtime_lookup),
|
||||
&key, &next_key) == 0) {
|
||||
// 汇总来自所有 CPU 的值（percpu map）
|
||||
if (bpf_map_lookup_elem(bpf_map__fd(skel->maps.runtime_lookup),
|
||||
&next_key, values) == 0) {
|
||||
for (int i = 0; i < num_cpus; i++) {
|
||||
runtime_us += values[i];
|
||||
}
|
||||
|
||||
// 计算能量
|
||||
double energy_mj = (env.cpu_power_watts * runtime_us) / 1000000.0;
|
||||
printf("%-10d %-16s %-15.2f %-15.4f\n",
|
||||
next_key, comm, runtime_ms, energy_mj);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 构建和运行能源监控器
|
||||
|
||||
### 先决条件
|
||||
|
||||
在构建之前，需要确保系统环境满足几个基本要求。首先需要 Linux 内核 5.4 或更新版本，且支持 BTF（BPF 类型格式）功能。其次要安装 libbpf 开发文件，这是 eBPF 程序开发的基础库。编译 eBPF 程序需要 clang 和 llvm 工具链。最后，还需要安装基本的构建工具，包括 make 和 gcc。
|
||||
|
||||
### 编译
|
||||
|
||||
使用提供的 Makefile 构建所有组件：
|
||||
|
||||
```bash
|
||||
cd /yunwei37/bpf-developer-tutorial/src/48-energy
|
||||
make clean && make
|
||||
```
|
||||
|
||||
编译完成后会生成三个主要的可执行文件。`energy_monitor` 是基于 eBPF 的能源监控器，提供高精度的实时监控功能。`energy_monitor_traditional.sh` 是传统的基于轮询的监控器，使用 `/proc` 文件系统进行采样。`compare_monitors.sh` 则是用于比较两种方法效率和精度的脚本。
|
||||
|
||||
### 运行 eBPF 监控器
|
||||
|
||||
eBPF 监控器需要 root 权限才能附加到内核跟踪点：
|
||||
|
||||
```bash
|
||||
# 以 15W CPU 功率监控所有进程 10 秒
|
||||
sudo ./energy_monitor -d 10 -p 15.0
|
||||
|
||||
# 详细输出监控
|
||||
sudo ./energy_monitor -v -d 10
|
||||
|
||||
# 持续监控（Ctrl+C 停止）
|
||||
sudo ./energy_monitor
|
||||
```
|
||||
|
||||
示例输出：
|
||||
|
||||
```
|
||||
能源监控器已启动... 按 Ctrl-C 结束。
|
||||
CPU 功率：15.00 W
|
||||
运行 10 秒
|
||||
|
||||
=== 能源使用摘要 ===
|
||||
PID COMM 运行时间 (ms) 能量 (mJ)
|
||||
---------- ---------------- --------------- ---------------
|
||||
39716 firefox 541.73 8.1260
|
||||
19845 node 67.71 1.0157
|
||||
39719 vscode 63.15 0.9472
|
||||
29712 chrome 13.34 0.2000
|
||||
...
|
||||
|
||||
总 CPU 时间：2781.52 ms
|
||||
总估计能量：0.0417 J (41.7229 mJ)
|
||||
CPU 功率设置：15.00 W
|
||||
```
|
||||
|
||||
### 运行传统监控器
|
||||
|
||||
传统监控器使用 `/proc` 采样，无需特殊权限即可运行：
|
||||
|
||||
```bash
|
||||
# 详细输出监控 10 秒
|
||||
./energy_monitor_traditional.sh -d 10 -v
|
||||
|
||||
# 调整采样间隔（默认 100ms）
|
||||
./energy_monitor_traditional.sh -d 10 -i 0.05
|
||||
```
|
||||
|
||||
### 比较两种方法
|
||||
|
||||
使用比较脚本查看差异：
|
||||
|
||||
```bash
|
||||
# 基本比较
|
||||
sudo ./compare_monitors.sh -d 10
|
||||
|
||||
# 带有 CPU 工作负载
|
||||
sudo ./compare_monitors.sh -d 10 -w "stress --cpu 2 --timeout 10"
|
||||
```
|
||||
|
||||
比较输出示例：
|
||||
|
||||
```
|
||||
比较结果
|
||||
==================
|
||||
|
||||
指标 传统 eBPF
|
||||
------------------------- --------------- ---------------
|
||||
总能量 (J) 1.050000 0.0288
|
||||
监控时间 (s) 5.112031 4.500215
|
||||
样本/事件 50 连续
|
||||
|
||||
性能分析：
|
||||
- 传统监控开销：与 eBPF 相比为 13.00%
|
||||
- eBPF 提供每个上下文切换的粒度
|
||||
- 传统采样以固定间隔（100ms）
|
||||
```
|
||||
|
||||
## 理解能源监控权衡
|
||||
|
||||
虽然我们的能源监控器提供了有价值的见解，但了解其局限性和权衡很重要：
|
||||
|
||||
### 精度考虑
|
||||
|
||||
我们的能源监控模型采用简化方法，使用公式：能量 = CPU_功率 × CPU_时间。虽然这提供了有价值的比较见解，但它没有考虑影响实际功耗的几个动态因素。
|
||||
|
||||
**频率调节**是一个重要限制，因为现代 CPU 根据工作负载和热条件动态改变频率。不同的**空闲状态**（C 状态）也消耗不同的功率，从深度睡眠中的接近零到浅空闲状态中的显著待机功率。此外，**工作负载特性**很重要，因为某些指令（特别是向量操作和内存密集型任务）每个周期消耗的功率比简单的算术运算更多。
|
||||
|
||||
该模型还忽略了来自缓存、内存控制器和 I/O 子系统的**共享资源消耗**，这些都有助于总系统功率，但不能直接归因于 CPU 执行时间。
|
||||
|
||||
对于需要更高精度的生产部署，增强功能将包括读取硬件性能计数器以进行实际功率测量，通过 DVFS 事件跟踪频率变化，基于性能计数器对不同指令类型进行建模，以及合并来自更广泛系统的内存和 I/O 活动指标。
|
||||
|
||||
### 何时使用每种方法
|
||||
|
||||
在 eBPF 和传统监控之间进行选择取决于您的具体要求和约束。
|
||||
|
||||
**eBPF 监控**在您需要准确的 CPU 时间跟踪时表现出色，特别是对于传统采样可能完全错过的短暂进程。其最小的测量开销使其成为生产环境的理想选择，在生产环境中，监控工具本身不应影响被测量的工作负载。eBPF 对于进程之间的比较分析特别有价值，其中相对精度比绝对精度更重要。
|
||||
|
||||
**传统监控**在由于权限限制或缺少 BTF 支持的旧内核版本而无法使用 eBPF 时仍然适用。它提供了一个简单、可移植的解决方案，不需要特殊权限，可以跨不同平台工作。对于监控长时间运行的稳定工作负载，其中近似测量就足够了，传统方法提供了足够的洞察力，部署要求更简单。
|
||||
|
||||
## 实际用例和部署场景
|
||||
|
||||
了解何时以及如何部署 eBPF 能源监控有助于最大化其价值。以下是它表现出色的现实场景：
|
||||
|
||||
### 数据中心能源优化
|
||||
|
||||
现代数据中心在严格的功率预算和冷却约束下运行，eBPF 能源监控提供了关键的运营能力。当调度器了解不同应用程序的能源配置文件时，**工作负载放置**变得智能化，从而在机架之间实现平衡的功耗，同时避免热点并最大化整体效率。
|
||||
|
||||
在高峰需求期间，**功率上限**系统可以利用实时能源归因来识别和选择性地限制最耗电的进程，而不影响关键服务。这种外科手术方法在保持在电力基础设施限制内的同时维持服务水平。
|
||||
|
||||
对于云提供商，**计费和退款**准确性推动客户行为朝着更高效的代码发展。当客户可以看到其工作负载的实际能源成本时，他们有直接的财务激励来优化其应用程序的能源效率。
|
||||
|
||||
### 移动和边缘计算
|
||||
|
||||
电池供电设备提出了独特的能源约束，其中精确监控对于用户体验和设备寿命至关重要。**应用程序能源分析**使开发人员能够在不同操作期间获得准确的能源消耗数据，从而实现有针对性的优化，可以显著延长电池寿命而不牺牲功能。
|
||||
|
||||
操作系统受益于**后台任务管理**智能，其中历史能源消耗模式告知有关允许或推迟哪些后台任务的决策。这可以防止耗能的后台进程耗尽电池，同时维护基本服务。
|
||||
|
||||
在没有主动冷却的设备中，**热管理**变得至关重要，因为能源监控有助于在节流发生之前预测热量积累。通过了解能源模式，系统可以主动管理工作负载，以在热限制内保持一致的性能。
|
||||
|
||||
### 开发和 CI/CD 集成
|
||||
|
||||
将能源监控集成到开发工作流中会创建一个连续的反馈循环，防止效率倒退到达生产环境。**能源回归测试**通过 CI/CD 管道变得自动化，这些管道标记将能源消耗增加到预定义阈值以上的代码更改，将能源效率视为一流的软件质量指标。
|
||||
|
||||
**性能/瓦特优化**为开发人员提供了对性能改进的真实成本的可见性。一些优化可能会提高速度，同时大幅增加能源消耗，而另一些可能会以最小的性能影响实现更好的效率。这种可见性支持基于实际工作负载要求的明智架构决策，平衡速度和效率。
|
||||
|
||||
**绿色软件指标**集成允许组织跟踪和报告能源效率作为可持续性计划的一部分。定期测量为环境影响报告提供了具体数据，同时为软件团队创建了在其开发实践中考虑能源效率的问责制。
|
||||
|
||||
### 研究和教育
|
||||
|
||||
eBPF 能源监控作为一种强大的研究和教育工具，弥合了理论理解和实际系统行为之间的差距。当研究人员可以在生产现实条件下测量方法之间的能源效率差异时，**算法比较**变得严格，提供了补充理论复杂性分析的经验数据。
|
||||
|
||||
**系统行为分析**从能源角度揭示了不同组件之间的复杂交互，发现了仅查看性能指标时不明显的优化机会。这些见解推动了考虑总拥有成本（包括运营能源成本）的系统设计决策。
|
||||
|
||||
作为**教学工具**，能源监控通过向学生展示其代码的即时能源影响，使抽象概念变得具体。当算法复杂性讨论与真实能源测量配对时，学生们对其设计选择的实际影响有了直觉，而不仅仅是计算效率。
|
||||
|
||||
## 扩展能源监控器
|
||||
|
||||
当前的实现为构建更复杂的能源监控功能提供了坚实的基础，有多个扩展方向值得探索。**硬件计数器集成**是最有影响力的增强方向，通过 `PERF_TYPE_POWER` 事件集成 RAPL 计数器，可以用实际的硬件测量来替换我们的估算模型，大幅提升精度。**每核功率建模**在处理异构处理器时尤为重要，通过跟踪进程的核心分配并建模性能核心（P 核）与效率核心（E 核）之间的功耗差异，能够实现更准确的能源归因。**工作负载分类**功能可以识别 CPU 密集型、内存绑定、I/O 绑定和空闲模式等不同工作负载类型，从而实现针对特定工作负载的功率优化策略。**容器运行时集成**使得系统能够按容器或 pod 聚合 Kubernetes 环境中的能源消耗，支持云原生的能源归因和计费。**实时可视化**通过提供带有能源消耗图表的 Web 仪表板，为能源优化提供即时的视觉反馈。
|
||||
|
||||
**硬件计数器集成**代表了最有影响力的增强，通过 RAPL（运行平均功率限制）接口用实际硬件测量替换我们的简化估计模型。现代处理器提供详细的能源计数器，可以通过性能事件读取，提供精确到单个 CPU 封装的能源测量。
|
||||
|
||||
```c
|
||||
// 读取 RAPL 计数器以获取实际能源测量
|
||||
struct perf_event_attr attr = {
|
||||
.type = PERF_TYPE_POWER,
|
||||
.config = PERF_COUNT_HW_POWER_PKG,
|
||||
};
|
||||
```
|
||||
|
||||
**每核功率建模**在异构处理器上变得至关重要，其中性能核心和效率核心具有截然不同的功率特性。跟踪每个进程在哪个核心上运行可以实现准确的能源归因：
|
||||
|
||||
```c
|
||||
// 不同的核心可能具有不同的功率特性
|
||||
double core_power[MAX_CPUS] = {15.0, 15.0, 10.0, 10.0}; // P 核与 E 核
|
||||
```
|
||||
|
||||
**工作负载分类**通过识别不同的计算模式及其相关的能源成本来增强能源监控：
|
||||
|
||||
```c
|
||||
enum workload_type {
|
||||
WORKLOAD_CPU_INTENSIVE,
|
||||
WORKLOAD_MEMORY_BOUND,
|
||||
WORKLOAD_IO_BOUND,
|
||||
WORKLOAD_IDLE
|
||||
};
|
||||
```
|
||||
|
||||
## 故障排除常见问题
|
||||
|
||||
部署 eBPF 能源监控时，您可能会遇到这些常见问题：
|
||||
|
||||
### 权限被拒绝
|
||||
|
||||
如果在运行 eBPF 监控器时看到权限错误：
|
||||
|
||||
```bash
|
||||
# 检查 BPF 是否已启用
|
||||
sudo sysctl kernel.unprivileged_bpf_disabled
|
||||
|
||||
# 启用 BPF 进行调试（不建议用于生产）
|
||||
sudo sysctl kernel.unprivileged_bpf_disabled=0
|
||||
```
|
||||
|
||||
### 缺少 BTF 信息
|
||||
|
||||
如果内核缺少 BTF（BPF 类型格式）数据：
|
||||
|
||||
```bash
|
||||
# 检查 BTF 支持
|
||||
ls /sys/kernel/btf/vmlinux
|
||||
|
||||
# 在较旧的内核上，您可能需要生成 BTF
|
||||
# 或使用带有 CONFIG_DEBUG_INFO_BTF=y 的内核
|
||||
```
|
||||
|
||||
### 高 CPU 使用率
|
||||
|
||||
如果监控器本身导致高 CPU 使用率，可以采取几种优化措施。首先考虑减少 eBPF 程序中的环形缓冲区大小，这能够降低内存压力和处理开销。其次，增加批量读取事件的大小可以减少系统调用的频率。最有效的方法是在内核中添加事件过滤逻辑，从源头上减少需要传递到用户空间的事件数量。
|
||||
|
||||
### 缺少进程
|
||||
|
||||
当发现某些进程没有被正确跟踪时，需要从几个方面进行排查。首先检查这些进程是否运行在不同的 PID 命名空间中，容器化环境经常会出现这种情况。其次，确保监控器在目标进程启动之前就已经运行，否则可能会错过初始的调度事件。最后，验证 eBPF 程序中的哈希映射大小是否足够容纳所有需要跟踪的进程，必要时可以增加 `max_entries` 的值。
|
||||
|
||||
## 未来方向
|
||||
|
||||
基于 eBPF 的能源监控领域正在迅速发展。以下是即将到来的令人兴奋的发展：
|
||||
|
||||
### 与硬件加速器集成
|
||||
|
||||
随着 GPU、TPU 和其他加速器变得普遍，扩展 eBPF 监控以跟踪其能源消耗将提供完整的系统可见性。
|
||||
|
||||
### 用于功率预测的机器学习
|
||||
|
||||
使用 eBPF 收集的数据来训练模型，这些模型基于工作负载模式预测未来的功耗，从而实现主动电源管理。
|
||||
|
||||
### 标准化工作
|
||||
|
||||
正在进行标准化 eBPF 能源监控接口的工作，使构建跨不同平台工作的可移植工具变得更加容易。
|
||||
|
||||
### 碳感知计算
|
||||
|
||||
将能源监控与实时碳强度数据相结合，自动将工作负载转移到具有更清洁能源的时间和地点。
|
||||
|
||||
## 参考文献和进一步阅读
|
||||
|
||||
要深入了解本教程中涵盖的主题：
|
||||
|
||||
### 能源和电源管理
|
||||
|
||||
在能源和电源管理领域，有几个重要的参考资源值得深入研究。Intel 的运行平均功率限制 (RAPL) 文档（[https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html](https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/running-average-power-limit-energy-reporting.html)）详细解释了如何使用硬件计数器进行精确的能源测量。Linux 电源管理文档（[https://www.kernel.org/doc/html/latest/admin-guide/pm/index.html](https://www.kernel.org/doc/html/latest/admin-guide/pm/index.html)）提供了内核电源管理子系统的全面指南。而 ACPI 规范（[https://uefi.org/specifications](https://uefi.org/specifications)）则定义了现代系统电源管理的标准接口。
|
||||
|
||||
### 相关项目
|
||||
|
||||
在能源监控生态系统中，有许多值得关注的项目。Kepler（Kubernetes 高效功率级别导出器）作为 CNCF 项目，专门为云原生环境提供能源监控解决方案（[https://sustainable-computing.io/](https://sustainable-computing.io/)）。Scaphandre（[https://github.com/hubblo-org/scaphandre](https://github.com/hubblo-org/scaphandre)）提供了另一种功率测量实现，支持多种硬件平台。经典的 PowerTOP 工具（[https://github.com/fenrus75/powertop](https://github.com/fenrus75/powertop)）一直是 Linux 系统上诊断电源问题的首选工具。最近的 cpufreq_ext eBPF 调节器（[https://lwn.net/Articles/991991/](https://lwn.net/Articles/991991/)）展示了使用 eBPF 进行动态频率调节的可能性。Wattmeter 项目在 HotCarbon '24 会议上的展示（[https://www.asafcidon.com/uploads/5/9/7/0/59701649/energy-aware-ebpf.pdf](https://www.asafcidon.com/uploads/5/9/7/0/59701649/energy-aware-ebpf.pdf)）则代表了该领域的最新研究成果。
|
||||
|
||||
### 学术论文
|
||||
|
||||
学术界对 eBPF 能源监控的研究日益活跃。HotCarbon '24 会议上发表的 "Linux 中的能源感知进程调度" 论文提出了创新的调度算法。"DEEP-mon：基于容器的基础设施的动态和节能功率监控" 研究展示了如何在容器化环境中实现高效的能源监控。而 "基于 eBPF 的能源感知调度" 等研究论文则探索了将能源感知与任务调度紧密结合的新方法。
|
||||
|
||||
本教程的完整代码可在以下位置获得：[https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/main/src/48-energy](https://github.com/eunomia-bpf/bpf-developer-tutorial/tree/main/src/48-energy)
|
||||
|
||||
有关更多 eBPF 教程和项目，请访问：[https://eunomia.dev/tutorials/](https://eunomia.dev/tutorials/)
|
||||
|
||||
## 结论
|
||||
|
||||
随着我们努力实现更可持续的计算，能源监控变得越来越重要。本教程演示了 eBPF 如何在进程级别提供精确、低开销的能源归因，使开发人员和系统管理员能够就能源效率做出明智的决策。
|
||||
|
||||
eBPF 的内核集成和高效事件处理的结合使其成为生产能源监控的理想选择。无论您是优化数据中心工作负载、延长移动设备的电池寿命，还是只是对应用程序的能源足迹感到好奇，eBPF 都提供了您进行详细分析所需的工具。
|
||||
|
||||
随着生态系统的成熟，像 Kepler 这样的项目已经投入生产，cpufreq_ext 正在接近主线包含，我们正在进入一个能源感知计算成为默认而不是事后想法的时代。立即开始监控您的应用程序的能源消耗，为更可持续的计算未来做出贡献！
|
||||
@@ -1,112 +0,0 @@
|
||||
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
||||
/* Copyright (c) 2020 Facebook */
|
||||
#include "vmlinux.h"
|
||||
#include <bpf/bpf_helpers.h>
|
||||
#include <bpf/bpf_tracing.h>
|
||||
#include <bpf/bpf_core_read.h>
|
||||
#include "bootstrap.h"
|
||||
|
||||
char LICENSE[] SEC("license") = "Dual BSD/GPL";
|
||||
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_HASH);
|
||||
__uint(max_entries, 8192);
|
||||
__type(key, pid_t);
|
||||
__type(value, u64);
|
||||
} exec_start SEC(".maps");
|
||||
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_RINGBUF);
|
||||
__uint(max_entries, 256 * 1024);
|
||||
} rb SEC(".maps");
|
||||
|
||||
const volatile unsigned long long min_duration_ns = 0;
|
||||
|
||||
SEC("tp/sched/sched_process_exec")
|
||||
int handle_exec(struct trace_event_raw_sched_process_exec *ctx)
|
||||
{
|
||||
struct task_struct *task;
|
||||
unsigned fname_off;
|
||||
struct event *e;
|
||||
pid_t pid;
|
||||
u64 ts;
|
||||
|
||||
/* remember time exec() was executed for this PID */
|
||||
pid = bpf_get_current_pid_tgid() >> 32;
|
||||
ts = bpf_ktime_get_ns();
|
||||
bpf_map_update_elem(&exec_start, &pid, &ts, BPF_ANY);
|
||||
|
||||
/* don't emit exec events when minimum duration is specified */
|
||||
if (min_duration_ns)
|
||||
return 0;
|
||||
|
||||
/* reserve sample from BPF ringbuf */
|
||||
e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
|
||||
if (!e)
|
||||
return 0;
|
||||
|
||||
/* fill out the sample with data */
|
||||
task = (struct task_struct *)bpf_get_current_task();
|
||||
|
||||
e->exit_event = false;
|
||||
e->pid = pid;
|
||||
e->ppid = BPF_CORE_READ(task, real_parent, tgid);
|
||||
bpf_get_current_comm(&e->comm, sizeof(e->comm));
|
||||
|
||||
fname_off = ctx->__data_loc_filename & 0xFFFF;
|
||||
bpf_probe_read_str(&e->filename, sizeof(e->filename), (void *)ctx + fname_off);
|
||||
|
||||
/* successfully submit it to user-space for post-processing */
|
||||
bpf_ringbuf_submit(e, 0);
|
||||
return 0;
|
||||
}
|
||||
|
||||
SEC("tp/sched/sched_process_exit")
|
||||
int handle_exit(struct trace_event_raw_sched_process_template* ctx)
|
||||
{
|
||||
struct task_struct *task;
|
||||
struct event *e;
|
||||
pid_t pid, tid;
|
||||
u64 id, ts, *start_ts, duration_ns = 0;
|
||||
|
||||
/* get PID and TID of exiting thread/process */
|
||||
id = bpf_get_current_pid_tgid();
|
||||
pid = id >> 32;
|
||||
tid = (u32)id;
|
||||
|
||||
/* ignore thread exits */
|
||||
if (pid != tid)
|
||||
return 0;
|
||||
|
||||
/* if we recorded start of the process, calculate lifetime duration */
|
||||
start_ts = bpf_map_lookup_elem(&exec_start, &pid);
|
||||
if (start_ts)
|
||||
duration_ns = bpf_ktime_get_ns() - *start_ts;
|
||||
else if (min_duration_ns)
|
||||
return 0;
|
||||
bpf_map_delete_elem(&exec_start, &pid);
|
||||
|
||||
/* if process didn't live long enough, return early */
|
||||
if (min_duration_ns && duration_ns < min_duration_ns)
|
||||
return 0;
|
||||
|
||||
/* reserve sample from BPF ringbuf */
|
||||
e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
|
||||
if (!e)
|
||||
return 0;
|
||||
|
||||
/* fill out the sample with data */
|
||||
task = (struct task_struct *)bpf_get_current_task();
|
||||
|
||||
e->exit_event = true;
|
||||
e->duration_ns = duration_ns;
|
||||
e->pid = pid;
|
||||
e->ppid = BPF_CORE_READ(task, real_parent, tgid);
|
||||
e->exit_code = (BPF_CORE_READ(task, exit_code) >> 8) & 0xff;
|
||||
bpf_get_current_comm(&e->comm, sizeof(e->comm));
|
||||
|
||||
/* send data to user-space for post-processing */
|
||||
bpf_ringbuf_submit(e, 0);
|
||||
return 0;
|
||||
}
|
||||
|
||||
@@ -1,173 +0,0 @@
|
||||
// SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
|
||||
/* Copyright (c) 2020 Facebook */
|
||||
#include <argp.h>
|
||||
#include <signal.h>
|
||||
#include <stdio.h>
|
||||
#include <time.h>
|
||||
#include <sys/resource.h>
|
||||
#include <bpf/libbpf.h>
|
||||
#include "bootstrap.h"
|
||||
#include "bootstrap.skel.h"
|
||||
|
||||
static struct env {
|
||||
bool verbose;
|
||||
long min_duration_ms;
|
||||
} env;
|
||||
|
||||
const char *argp_program_version = "bootstrap 0.0";
|
||||
const char *argp_program_bug_address = "<bpf@vger.kernel.org>";
|
||||
const char argp_program_doc[] =
|
||||
"BPF bootstrap demo application.\n"
|
||||
"\n"
|
||||
"It traces process start and exits and shows associated \n"
|
||||
"information (filename, process duration, PID and PPID, etc).\n"
|
||||
"\n"
|
||||
"USAGE: ./bootstrap [-d <min-duration-ms>] [-v]\n";
|
||||
|
||||
static const struct argp_option opts[] = {
|
||||
{ "verbose", 'v', NULL, 0, "Verbose debug output" },
|
||||
{ "duration", 'd', "DURATION-MS", 0, "Minimum process duration (ms) to report" },
|
||||
{},
|
||||
};
|
||||
|
||||
static error_t parse_arg(int key, char *arg, struct argp_state *state)
|
||||
{
|
||||
switch (key) {
|
||||
case 'v':
|
||||
env.verbose = true;
|
||||
break;
|
||||
case 'd':
|
||||
errno = 0;
|
||||
env.min_duration_ms = strtol(arg, NULL, 10);
|
||||
if (errno || env.min_duration_ms <= 0) {
|
||||
fprintf(stderr, "Invalid duration: %s\n", arg);
|
||||
argp_usage(state);
|
||||
}
|
||||
break;
|
||||
case ARGP_KEY_ARG:
|
||||
argp_usage(state);
|
||||
break;
|
||||
default:
|
||||
return ARGP_ERR_UNKNOWN;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
static const struct argp argp = {
|
||||
.options = opts,
|
||||
.parser = parse_arg,
|
||||
.doc = argp_program_doc,
|
||||
};
|
||||
|
||||
static int libbpf_print_fn(enum libbpf_print_level level, const char *format, va_list args)
|
||||
{
|
||||
if (level == LIBBPF_DEBUG && !env.verbose)
|
||||
return 0;
|
||||
return vfprintf(stderr, format, args);
|
||||
}
|
||||
|
||||
static volatile bool exiting = false;
|
||||
|
||||
static void sig_handler(int sig)
|
||||
{
|
||||
exiting = true;
|
||||
}
|
||||
|
||||
static int handle_event(void *ctx, void *data, size_t data_sz)
|
||||
{
|
||||
const struct event *e = data;
|
||||
struct tm *tm;
|
||||
char ts[32];
|
||||
time_t t;
|
||||
|
||||
time(&t);
|
||||
tm = localtime(&t);
|
||||
strftime(ts, sizeof(ts), "%H:%M:%S", tm);
|
||||
|
||||
if (e->exit_event) {
|
||||
printf("%-8s %-5s %-16s %-7d %-7d [%u]",
|
||||
ts, "EXIT", e->comm, e->pid, e->ppid, e->exit_code);
|
||||
if (e->duration_ns)
|
||||
printf(" (%llums)", e->duration_ns / 1000000);
|
||||
printf("\n");
|
||||
} else {
|
||||
printf("%-8s %-5s %-16s %-7d %-7d %s\n",
|
||||
ts, "EXEC", e->comm, e->pid, e->ppid, e->filename);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
struct ring_buffer *rb = NULL;
|
||||
struct bootstrap_bpf *skel;
|
||||
int err;
|
||||
|
||||
/* Parse command line arguments */
|
||||
err = argp_parse(&argp, argc, argv, 0, NULL, NULL);
|
||||
if (err)
|
||||
return err;
|
||||
|
||||
/* Set up libbpf errors and debug info callback */
|
||||
libbpf_set_print(libbpf_print_fn);
|
||||
|
||||
/* Cleaner handling of Ctrl-C */
|
||||
signal(SIGINT, sig_handler);
|
||||
signal(SIGTERM, sig_handler);
|
||||
|
||||
/* Load and verify BPF application */
|
||||
skel = bootstrap_bpf__open();
|
||||
if (!skel) {
|
||||
fprintf(stderr, "Failed to open and load BPF skeleton\n");
|
||||
return 1;
|
||||
}
|
||||
|
||||
/* Parameterize BPF code with minimum duration parameter */
|
||||
skel->rodata->min_duration_ns = env.min_duration_ms * 1000000ULL;
|
||||
|
||||
/* Load & verify BPF programs */
|
||||
err = bootstrap_bpf__load(skel);
|
||||
if (err) {
|
||||
fprintf(stderr, "Failed to load and verify BPF skeleton\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
/* Attach tracepoints */
|
||||
err = bootstrap_bpf__attach(skel);
|
||||
if (err) {
|
||||
fprintf(stderr, "Failed to attach BPF skeleton\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
/* Set up ring buffer polling */
|
||||
rb = ring_buffer__new(bpf_map__fd(skel->maps.rb), handle_event, NULL, NULL);
|
||||
if (!rb) {
|
||||
err = -1;
|
||||
fprintf(stderr, "Failed to create ring buffer\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
/* Process events */
|
||||
printf("%-8s %-5s %-16s %-7s %-7s %s\n",
|
||||
"TIME", "EVENT", "COMM", "PID", "PPID", "FILENAME/EXIT CODE");
|
||||
while (!exiting) {
|
||||
err = ring_buffer__poll(rb, 100 /* timeout, ms */);
|
||||
/* Ctrl-C will cause -EINTR */
|
||||
if (err == -EINTR) {
|
||||
err = 0;
|
||||
break;
|
||||
}
|
||||
if (err < 0) {
|
||||
printf("Error polling perf buffer: %d\n", err);
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
cleanup:
|
||||
/* Clean up */
|
||||
ring_buffer__free(rb);
|
||||
bootstrap_bpf__destroy(skel);
|
||||
|
||||
return err < 0 ? -err : 0;
|
||||
}
|
||||
@@ -1,19 +0,0 @@
|
||||
/* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
|
||||
/* Copyright (c) 2020 Facebook */
|
||||
#ifndef __BOOTSTRAP_H
|
||||
#define __BOOTSTRAP_H
|
||||
|
||||
#define TASK_COMM_LEN 16
|
||||
#define MAX_FILENAME_LEN 127
|
||||
|
||||
struct event {
|
||||
int pid;
|
||||
int ppid;
|
||||
unsigned exit_code;
|
||||
unsigned long long duration_ns;
|
||||
char comm[TASK_COMM_LEN];
|
||||
char filename[MAX_FILENAME_LEN];
|
||||
bool exit_event;
|
||||
};
|
||||
|
||||
#endif /* __BOOTSTRAP_H */
|
||||
128
src/48-energy/compare_monitors.sh
Executable file
128
src/48-energy/compare_monitors.sh
Executable file
@@ -0,0 +1,128 @@
|
||||
#!/bin/bash
|
||||
# Script to compare eBPF and traditional energy monitoring approaches
|
||||
|
||||
set -e
|
||||
|
||||
echo "Energy Monitor Comparison Tool"
|
||||
echo "=============================="
|
||||
echo ""
|
||||
|
||||
# Check if we're running as root (required for eBPF)
|
||||
if [ "$EUID" -ne 0 ]; then
|
||||
echo "Please run as root (required for eBPF)"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Default parameters
|
||||
DURATION=10
|
||||
CPU_POWER=15.0
|
||||
WORKLOAD=""
|
||||
|
||||
# Parse arguments
|
||||
while getopts "d:p:w:" opt; do
|
||||
case $opt in
|
||||
d) DURATION=$OPTARG ;;
|
||||
p) CPU_POWER=$OPTARG ;;
|
||||
w) WORKLOAD=$OPTARG ;;
|
||||
?) echo "Usage: $0 [-d duration] [-p power_watts] [-w 'workload command']"
|
||||
exit 1 ;;
|
||||
esac
|
||||
done
|
||||
|
||||
# Build eBPF program if needed
|
||||
if [ ! -f "energy_monitor" ]; then
|
||||
echo "Building eBPF energy monitor..."
|
||||
make energy_monitor
|
||||
fi
|
||||
|
||||
# Function to run a monitor
|
||||
run_monitor() {
|
||||
local monitor_type=$1
|
||||
local output_file=$2
|
||||
|
||||
echo "Running $monitor_type monitor for ${DURATION} seconds..."
|
||||
|
||||
if [ "$monitor_type" = "eBPF" ]; then
|
||||
./energy_monitor -d $DURATION -p $CPU_POWER > $output_file 2>&1
|
||||
else
|
||||
./energy_monitor_traditional.sh -d $DURATION -p $CPU_POWER -i 0.1 > $output_file 2>&1
|
||||
fi
|
||||
}
|
||||
|
||||
# Start workload if specified
|
||||
if [ -n "$WORKLOAD" ]; then
|
||||
echo "Starting workload: $WORKLOAD"
|
||||
eval "$WORKLOAD" &
|
||||
WORKLOAD_PID=$!
|
||||
sleep 1
|
||||
fi
|
||||
|
||||
# Run traditional monitor
|
||||
echo ""
|
||||
echo "Phase 1: Traditional /proc-based monitoring"
|
||||
echo "-------------------------------------------"
|
||||
START_TIME=$(date +%s.%N)
|
||||
run_monitor "traditional" /tmp/traditional_output.txt
|
||||
END_TIME=$(date +%s.%N)
|
||||
TRADITIONAL_TIME=$(echo "$END_TIME - $START_TIME" | bc)
|
||||
|
||||
# Extract traditional results
|
||||
TRADITIONAL_TOTAL=$(grep "Total estimated energy:" /tmp/traditional_output.txt | awk '{print $4}')
|
||||
TRADITIONAL_SAMPLES=$(grep "Samples collected:" /tmp/traditional_output.txt | awk '{print $3}')
|
||||
|
||||
# Wait a bit between tests
|
||||
sleep 2
|
||||
|
||||
# Run eBPF monitor
|
||||
echo ""
|
||||
echo "Phase 2: eBPF-based monitoring"
|
||||
echo "------------------------------"
|
||||
START_TIME=$(date +%s.%N)
|
||||
run_monitor "eBPF" /tmp/ebpf_output.txt
|
||||
END_TIME=$(date +%s.%N)
|
||||
EBPF_TIME=$(echo "$END_TIME - $START_TIME" | bc)
|
||||
|
||||
# Extract eBPF results
|
||||
EBPF_TOTAL=$(grep "Total estimated energy:" /tmp/ebpf_output.txt | grep -oE '[0-9]+\.[0-9]+ J' | awk '{print $1}')
|
||||
|
||||
# Stop workload if running
|
||||
if [ -n "$WORKLOAD_PID" ]; then
|
||||
kill $WORKLOAD_PID 2>/dev/null || true
|
||||
wait $WORKLOAD_PID 2>/dev/null || true
|
||||
fi
|
||||
|
||||
# Display comparison
|
||||
echo ""
|
||||
echo "Comparison Results"
|
||||
echo "=================="
|
||||
echo ""
|
||||
printf "%-25s %-15s %-15s\n" "Metric" "Traditional" "eBPF"
|
||||
printf "%-25s %-15s %-15s\n" "-------------------------" "---------------" "---------------"
|
||||
printf "%-25s %-15s %-15s\n" "Total Energy (J)" "$TRADITIONAL_TOTAL" "$EBPF_TOTAL"
|
||||
printf "%-25s %-15s %-15s\n" "Monitoring Time (s)" "$TRADITIONAL_TIME" "$EBPF_TIME"
|
||||
printf "%-25s %-15s %-15s\n" "Samples/Events" "$TRADITIONAL_SAMPLES" "Continuous"
|
||||
|
||||
# Calculate overhead
|
||||
OVERHEAD_PERCENT=$(echo "scale=2; ($TRADITIONAL_TIME - $EBPF_TIME) / $EBPF_TIME * 100" | bc)
|
||||
echo ""
|
||||
echo "Performance Analysis:"
|
||||
echo "- Traditional monitoring overhead: ${OVERHEAD_PERCENT}% compared to eBPF"
|
||||
echo "- eBPF provides per-context-switch granularity"
|
||||
echo "- Traditional samples at fixed intervals (100ms)"
|
||||
|
||||
# Show top processes from both
|
||||
echo ""
|
||||
echo "Top Energy Consumers (Traditional):"
|
||||
echo "-----------------------------------"
|
||||
grep -A 5 "PID.*COMM.*Runtime.*Energy" /tmp/traditional_output.txt | head -6
|
||||
|
||||
echo ""
|
||||
echo "Top Energy Consumers (eBPF):"
|
||||
echo "----------------------------"
|
||||
grep -A 5 "PID.*COMM.*Runtime.*Energy" /tmp/ebpf_output.txt | head -6
|
||||
|
||||
# Cleanup
|
||||
rm -f /tmp/traditional_output.txt /tmp/ebpf_output.txt
|
||||
|
||||
echo ""
|
||||
echo "Comparison complete!"
|
||||
@@ -1,102 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Debug script to check RAPL energy readings
|
||||
"""
|
||||
|
||||
import os
|
||||
import time
|
||||
|
||||
def check_rapl():
|
||||
rapl_base = "/sys/class/powercap/intel-rapl"
|
||||
|
||||
print("Checking Intel RAPL availability...")
|
||||
print("=" * 50)
|
||||
|
||||
if not os.path.exists(rapl_base):
|
||||
print(f"ERROR: {rapl_base} does not exist!")
|
||||
print("Intel RAPL may not be available on this system.")
|
||||
return
|
||||
|
||||
# Check permissions
|
||||
print("\nChecking permissions...")
|
||||
for item in os.listdir(rapl_base):
|
||||
if item.startswith("intel-rapl:"):
|
||||
energy_file = os.path.join(rapl_base, item, "energy_uj")
|
||||
if os.path.exists(energy_file):
|
||||
readable = os.access(energy_file, os.R_OK)
|
||||
print(f"{energy_file}: {'readable' if readable else 'NOT readable'}")
|
||||
|
||||
print("\n" + "=" * 50)
|
||||
print("Reading energy values over 5 seconds...")
|
||||
print("=" * 50)
|
||||
|
||||
# Discover domains
|
||||
domains = {}
|
||||
for item in os.listdir(rapl_base):
|
||||
path = os.path.join(rapl_base, item)
|
||||
if os.path.isdir(path) and item.startswith("intel-rapl:"):
|
||||
try:
|
||||
with open(os.path.join(path, "name"), "r") as f:
|
||||
name = f.read().strip()
|
||||
energy_file = os.path.join(path, "energy_uj")
|
||||
if os.path.exists(energy_file):
|
||||
domains[name] = energy_file
|
||||
except:
|
||||
pass
|
||||
|
||||
if not domains:
|
||||
print("ERROR: No RAPL domains found!")
|
||||
return
|
||||
|
||||
print(f"Found domains: {', '.join(domains.keys())}\n")
|
||||
|
||||
# Read energy values multiple times
|
||||
readings = {domain: [] for domain in domains}
|
||||
|
||||
for i in range(10):
|
||||
for domain, energy_file in domains.items():
|
||||
try:
|
||||
with open(energy_file, "r") as f:
|
||||
energy = int(f.read().strip())
|
||||
readings[domain].append(energy)
|
||||
except Exception as e:
|
||||
print(f"Error reading {domain}: {e}")
|
||||
|
||||
time.sleep(0.5)
|
||||
|
||||
# Analyze readings
|
||||
print("\nAnalysis:")
|
||||
print("-" * 50)
|
||||
|
||||
for domain, values in readings.items():
|
||||
if len(values) < 2:
|
||||
continue
|
||||
|
||||
print(f"\n{domain}:")
|
||||
print(f" First reading: {values[0]} µJ")
|
||||
print(f" Last reading: {values[-1]} µJ")
|
||||
print(f" Difference: {values[-1] - values[0]} µJ")
|
||||
|
||||
# Check if values are changing
|
||||
unique_values = len(set(values))
|
||||
print(f" Unique values: {unique_values}")
|
||||
|
||||
if unique_values == 1:
|
||||
print(" ⚠️ WARNING: Energy values are not changing!")
|
||||
else:
|
||||
# Calculate average power
|
||||
energy_diff = values[-1] - values[0]
|
||||
time_diff = 0.5 * (len(values) - 1)
|
||||
if energy_diff > 0:
|
||||
power = (energy_diff / 1e6) / time_diff
|
||||
print(f" Average power: {power:.2f} W")
|
||||
|
||||
print("\n" + "=" * 50)
|
||||
print("\nPossible issues if readings are zero:")
|
||||
print("1. The system is idle with very low power consumption")
|
||||
print("2. RAPL updates may be infrequent (try longer sampling intervals)")
|
||||
print("3. Permission issues (try running with sudo)")
|
||||
print("4. RAPL may not be fully supported on this CPU")
|
||||
|
||||
if __name__ == "__main__":
|
||||
check_rapl()
|
||||
104
src/48-energy/energy_monitor.bpf.c
Normal file
104
src/48-energy/energy_monitor.bpf.c
Normal file
@@ -0,0 +1,104 @@
|
||||
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
||||
#include "vmlinux.h"
|
||||
#include <bpf/bpf_helpers.h>
|
||||
#include <bpf/bpf_tracing.h>
|
||||
#include <bpf/bpf_core_read.h>
|
||||
#include "energy_monitor.h"
|
||||
|
||||
char LICENSE[] SEC("license") = "Dual BSD/GPL";
|
||||
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32);
|
||||
__type(value, u64);
|
||||
} time_lookup SEC(".maps");
|
||||
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 10240);
|
||||
__type(key, u32);
|
||||
__type(value, u64);
|
||||
} runtime_lookup SEC(".maps");
|
||||
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_RINGBUF);
|
||||
__uint(max_entries, 256 * 1024);
|
||||
} rb SEC(".maps");
|
||||
|
||||
const volatile bool verbose = false;
|
||||
|
||||
static inline u64 div_u64_by_1000(u64 n) {
|
||||
u64 q, r, t;
|
||||
t = (n >> 7) + (n >> 8) + (n >> 12);
|
||||
q = (n >> 1) + t + (n >> 15) + (t >> 11) + (t >> 14);
|
||||
q = q >> 9;
|
||||
r = n - q * 1000;
|
||||
return q + ((r + 24) >> 10);
|
||||
}
|
||||
|
||||
static int update_runtime(u32 pid, u64 delta) {
|
||||
u64 time_delta_us = div_u64_by_1000(delta);
|
||||
u64 *current = bpf_map_lookup_elem(&runtime_lookup, &pid);
|
||||
|
||||
if (current) {
|
||||
time_delta_us += *current;
|
||||
}
|
||||
|
||||
return bpf_map_update_elem(&runtime_lookup, &pid, &time_delta_us, BPF_ANY);
|
||||
}
|
||||
|
||||
SEC("tp/sched/sched_switch")
|
||||
int monitor_energy(struct trace_event_raw_sched_switch *ctx)
|
||||
{
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
u32 cpu = bpf_get_smp_processor_id();
|
||||
struct energy_event *e;
|
||||
|
||||
u32 prev_pid = ctx->prev_pid;
|
||||
u32 next_pid = ctx->next_pid;
|
||||
|
||||
// Calculate runtime for the previous process
|
||||
u64 *old_ts_ptr = bpf_map_lookup_elem(&time_lookup, &prev_pid);
|
||||
if (old_ts_ptr) {
|
||||
u64 delta = ts - *old_ts_ptr;
|
||||
|
||||
if (verbose) {
|
||||
bpf_printk("CPU %d: PID %d ran for %llu ns", cpu, prev_pid, delta);
|
||||
}
|
||||
|
||||
// Update total runtime
|
||||
if (update_runtime(prev_pid, delta) != 0) {
|
||||
return 1;
|
||||
}
|
||||
|
||||
// Send event to userspace
|
||||
e = bpf_ringbuf_reserve(&rb, sizeof(*e), 0);
|
||||
if (e) {
|
||||
e->ts = ts;
|
||||
e->cpu = cpu;
|
||||
e->pid = prev_pid;
|
||||
e->runtime_ns = delta;
|
||||
bpf_probe_read_kernel_str(e->comm, sizeof(e->comm), ctx->prev_comm);
|
||||
|
||||
bpf_ringbuf_submit(e, 0);
|
||||
}
|
||||
}
|
||||
|
||||
// Record when the next process starts running
|
||||
bpf_map_update_elem(&time_lookup, &next_pid, &ts, BPF_ANY);
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
SEC("tracepoint/sched/sched_process_exit")
|
||||
int handle_exit(struct trace_event_raw_sched_process_template *ctx)
|
||||
{
|
||||
u32 pid = bpf_get_current_pid_tgid() >> 32;
|
||||
|
||||
// Clean up maps
|
||||
bpf_map_delete_elem(&time_lookup, &pid);
|
||||
bpf_map_delete_elem(&runtime_lookup, &pid);
|
||||
|
||||
return 0;
|
||||
}
|
||||
265
src/48-energy/energy_monitor.c
Normal file
265
src/48-energy/energy_monitor.c
Normal file
@@ -0,0 +1,265 @@
|
||||
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
||||
#include <argp.h>
|
||||
#include <signal.h>
|
||||
#include <stdio.h>
|
||||
#include <time.h>
|
||||
#include <sys/resource.h>
|
||||
#include <bpf/libbpf.h>
|
||||
#include <unistd.h>
|
||||
#include <stdlib.h>
|
||||
#include <string.h>
|
||||
#include <errno.h>
|
||||
#include <fcntl.h>
|
||||
#include "energy_monitor.h"
|
||||
#include "energy_monitor.skel.h"
|
||||
#include <bpf/bpf.h>
|
||||
|
||||
static volatile bool exiting = false;
|
||||
|
||||
static struct env {
|
||||
bool verbose;
|
||||
int duration;
|
||||
double cpu_power_watts; // CPU power in watts
|
||||
} env = {
|
||||
.verbose = false,
|
||||
.duration = 0,
|
||||
.cpu_power_watts = 15.0, // Default 15W per CPU
|
||||
};
|
||||
|
||||
const char *argp_program_version = "energy_monitor 0.1";
|
||||
const char *argp_program_bug_address = "<>";
|
||||
const char argp_program_doc[] =
|
||||
"eBPF-based energy monitoring tool.\n"
|
||||
"\n"
|
||||
"This tool monitors process energy consumption by tracking CPU time\n"
|
||||
"and estimating energy usage based on configured CPU power.\n"
|
||||
"\n"
|
||||
"USAGE: ./energy_monitor [-v] [-d <duration>] [-p <power>]\n";
|
||||
|
||||
static const struct argp_option opts[] = {
|
||||
{ "verbose", 'v', NULL, 0, "Verbose debug output" },
|
||||
{ "duration", 'd', "SECONDS", 0, "Duration to run (0 for infinite)" },
|
||||
{ "power", 'p', "WATTS", 0, "CPU power in watts (default: 15.0)" },
|
||||
{ NULL, 'h', NULL, OPTION_HIDDEN, "Show the full help" },
|
||||
{},
|
||||
};
|
||||
|
||||
static error_t parse_arg(int key, char *arg, struct argp_state *state)
|
||||
{
|
||||
switch (key) {
|
||||
case 'v':
|
||||
env.verbose = true;
|
||||
break;
|
||||
case 'd':
|
||||
env.duration = strtol(arg, NULL, 10);
|
||||
if (env.duration < 0) {
|
||||
fprintf(stderr, "Invalid duration: %s\n", arg);
|
||||
argp_usage(state);
|
||||
}
|
||||
break;
|
||||
case 'p':
|
||||
env.cpu_power_watts = strtod(arg, NULL);
|
||||
if (env.cpu_power_watts <= 0) {
|
||||
fprintf(stderr, "Invalid power value: %s\n", arg);
|
||||
argp_usage(state);
|
||||
}
|
||||
break;
|
||||
case 'h':
|
||||
argp_state_help(state, stderr, ARGP_HELP_STD_HELP);
|
||||
break;
|
||||
default:
|
||||
return ARGP_ERR_UNKNOWN;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
static const struct argp argp = {
|
||||
.options = opts,
|
||||
.parser = parse_arg,
|
||||
.doc = argp_program_doc,
|
||||
};
|
||||
|
||||
static int libbpf_print_fn(enum libbpf_print_level level, const char *format, va_list args)
|
||||
{
|
||||
if (level == LIBBPF_DEBUG && !env.verbose)
|
||||
return 0;
|
||||
return vfprintf(stderr, format, args);
|
||||
}
|
||||
|
||||
static void sig_handler(int sig)
|
||||
{
|
||||
exiting = true;
|
||||
}
|
||||
|
||||
static int handle_event(void *ctx, void *data, size_t data_sz)
|
||||
{
|
||||
const struct energy_event *e = data;
|
||||
static __u64 total_energy_nj = 0;
|
||||
|
||||
// Calculate energy in nanojoules
|
||||
// Energy (J) = Power (W) * Time (s)
|
||||
// Energy (nJ) = Power (W) * Time (ns)
|
||||
__u64 energy_nj = (__u64)(env.cpu_power_watts * e->runtime_ns);
|
||||
total_energy_nj += energy_nj;
|
||||
|
||||
if (env.verbose) {
|
||||
printf("%-16s pid=%-6d cpu=%-2d runtime=%llu ns energy=%llu nJ\n",
|
||||
e->comm, e->pid, e->cpu, e->runtime_ns, energy_nj);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void print_stats(struct energy_monitor_bpf *skel)
|
||||
{
|
||||
__u32 key = 0, next_key;
|
||||
__u64 total_runtime_us = 0;
|
||||
__u64 *values;
|
||||
int num_cpus = libbpf_num_possible_cpus();
|
||||
|
||||
values = calloc(num_cpus, sizeof(__u64));
|
||||
if (!values) {
|
||||
fprintf(stderr, "Failed to allocate memory\n");
|
||||
return;
|
||||
}
|
||||
|
||||
printf("\n=== Energy Usage Summary ===\n");
|
||||
printf("%-10s %-16s %-15s %-15s\n", "PID", "COMM", "Runtime (ms)", "Energy (mJ)");
|
||||
printf("%-10s %-16s %-15s %-15s\n", "----------", "----------------", "---------------", "---------------");
|
||||
|
||||
// Iterate through all PIDs in the runtime map
|
||||
while (bpf_map_get_next_key(bpf_map__fd(skel->maps.runtime_lookup), &key, &next_key) == 0) {
|
||||
char comm[TASK_COMM_LEN] = "unknown";
|
||||
__u64 runtime_us = 0;
|
||||
|
||||
if (bpf_map_lookup_elem(bpf_map__fd(skel->maps.runtime_lookup), &next_key, values) == 0) {
|
||||
// Sum up values from all CPUs
|
||||
for (int i = 0; i < num_cpus; i++) {
|
||||
runtime_us += values[i];
|
||||
}
|
||||
|
||||
// Try to get process name
|
||||
char path[256];
|
||||
snprintf(path, sizeof(path), "/proc/%d/comm", next_key);
|
||||
FILE *f = fopen(path, "r");
|
||||
if (f) {
|
||||
if (fgets(comm, sizeof(comm), f)) {
|
||||
comm[strcspn(comm, "\n")] = 0;
|
||||
}
|
||||
fclose(f);
|
||||
}
|
||||
|
||||
// Calculate energy in millijoules
|
||||
double runtime_ms = runtime_us / 1000.0;
|
||||
double energy_mj = (env.cpu_power_watts * runtime_us) / 1000000.0;
|
||||
|
||||
printf("%-10d %-16s %-15.2f %-15.4f\n", next_key, comm, runtime_ms, energy_mj);
|
||||
|
||||
total_runtime_us += runtime_us;
|
||||
}
|
||||
|
||||
key = next_key;
|
||||
}
|
||||
|
||||
double total_energy_j = (env.cpu_power_watts * total_runtime_us) / 1000000000.0;
|
||||
printf("\nTotal CPU time: %.2f ms\n", total_runtime_us / 1000.0);
|
||||
printf("Total estimated energy: %.4f J (%.4f mJ)\n", total_energy_j, total_energy_j * 1000);
|
||||
printf("CPU power setting: %.2f W\n", env.cpu_power_watts);
|
||||
|
||||
free(values);
|
||||
}
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
struct ring_buffer *rb = NULL;
|
||||
struct energy_monitor_bpf *skel;
|
||||
int err;
|
||||
|
||||
// Parse command line arguments
|
||||
err = argp_parse(&argp, argc, argv, 0, NULL, NULL);
|
||||
if (err)
|
||||
return err;
|
||||
|
||||
// Set up libbpf errors and debug info callback
|
||||
libbpf_set_print(libbpf_print_fn);
|
||||
|
||||
// Bump RLIMIT_MEMLOCK to create BPF maps
|
||||
struct rlimit rlim = {
|
||||
.rlim_cur = 512UL << 20, // 512 MB
|
||||
.rlim_max = 512UL << 20,
|
||||
};
|
||||
if (setrlimit(RLIMIT_MEMLOCK, &rlim)) {
|
||||
fprintf(stderr, "Failed to increase RLIMIT_MEMLOCK limit!\n");
|
||||
return 1;
|
||||
}
|
||||
|
||||
// Clean handling of Ctrl-C
|
||||
signal(SIGINT, sig_handler);
|
||||
signal(SIGTERM, sig_handler);
|
||||
|
||||
// Open and load BPF application
|
||||
skel = energy_monitor_bpf__open();
|
||||
if (!skel) {
|
||||
fprintf(stderr, "Failed to open BPF skeleton\n");
|
||||
return 1;
|
||||
}
|
||||
|
||||
// Set program parameters
|
||||
skel->rodata->verbose = env.verbose;
|
||||
|
||||
// Load & verify BPF programs
|
||||
err = energy_monitor_bpf__load(skel);
|
||||
if (err) {
|
||||
fprintf(stderr, "Failed to load and verify BPF skeleton\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
// Attach tracepoints
|
||||
err = energy_monitor_bpf__attach(skel);
|
||||
if (err) {
|
||||
fprintf(stderr, "Failed to attach BPF skeleton\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
// Set up ring buffer polling
|
||||
rb = ring_buffer__new(bpf_map__fd(skel->maps.rb), handle_event, NULL, NULL);
|
||||
if (!rb) {
|
||||
err = -1;
|
||||
fprintf(stderr, "Failed to create ring buffer\n");
|
||||
goto cleanup;
|
||||
}
|
||||
|
||||
printf("Energy monitor started... Hit Ctrl-C to end.\n");
|
||||
printf("CPU Power: %.2f W\n", env.cpu_power_watts);
|
||||
if (env.duration > 0)
|
||||
printf("Running for %d seconds\n", env.duration);
|
||||
printf("\n");
|
||||
|
||||
// Process events
|
||||
time_t start_time = time(NULL);
|
||||
while (!exiting) {
|
||||
err = ring_buffer__poll(rb, 100 /* timeout, ms */);
|
||||
// Ctrl-C will cause -EINTR
|
||||
if (err == -EINTR) {
|
||||
err = 0;
|
||||
break;
|
||||
}
|
||||
if (err < 0) {
|
||||
fprintf(stderr, "Error polling ring buffer: %d\n", err);
|
||||
break;
|
||||
}
|
||||
|
||||
// Check duration
|
||||
if (env.duration > 0 && (time(NULL) - start_time) >= env.duration)
|
||||
break;
|
||||
}
|
||||
|
||||
// Print final statistics
|
||||
print_stats(skel);
|
||||
|
||||
cleanup:
|
||||
ring_buffer__free(rb);
|
||||
energy_monitor_bpf__destroy(skel);
|
||||
|
||||
return err < 0 ? -err : 0;
|
||||
}
|
||||
15
src/48-energy/energy_monitor.h
Normal file
15
src/48-energy/energy_monitor.h
Normal file
@@ -0,0 +1,15 @@
|
||||
// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
|
||||
#ifndef __ENERGY_MONITOR_H
|
||||
#define __ENERGY_MONITOR_H
|
||||
|
||||
#define TASK_COMM_LEN 16
|
||||
|
||||
struct energy_event {
|
||||
__u64 ts;
|
||||
__u32 cpu;
|
||||
__u32 pid;
|
||||
__u64 runtime_ns;
|
||||
char comm[TASK_COMM_LEN];
|
||||
};
|
||||
|
||||
#endif /* __ENERGY_MONITOR_H */
|
||||
@@ -1,473 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
|
||||
import os
|
||||
import time
|
||||
import json
|
||||
import csv
|
||||
from datetime import datetime
|
||||
from collections import deque
|
||||
import matplotlib.pyplot as plt
|
||||
import matplotlib.animation as animation
|
||||
from matplotlib.figure import Figure
|
||||
|
||||
class RAPLEnergyMonitor:
|
||||
def __init__(self):
|
||||
self.rapl_base = "/sys/class/powercap/intel-rapl"
|
||||
self.energy_data = {}
|
||||
self.timestamps = deque(maxlen=100)
|
||||
self.power_data = {}
|
||||
self.domains = self._discover_domains()
|
||||
|
||||
def _discover_domains(self):
|
||||
domains = {}
|
||||
if not os.path.exists(self.rapl_base):
|
||||
raise RuntimeError("Intel RAPL not available. Are you running on Intel CPU with appropriate permissions?")
|
||||
|
||||
for item in os.listdir(self.rapl_base):
|
||||
path = os.path.join(self.rapl_base, item)
|
||||
if os.path.isdir(path) and item.startswith("intel-rapl:"):
|
||||
try:
|
||||
with open(os.path.join(path, "name"), "r") as f:
|
||||
name = f.read().strip()
|
||||
domains[name] = {
|
||||
"path": path,
|
||||
"energy_file": os.path.join(path, "energy_uj"),
|
||||
"max_energy": self._read_max_energy(path),
|
||||
"last_energy": None,
|
||||
"last_time": None
|
||||
}
|
||||
except:
|
||||
continue
|
||||
|
||||
# Check for subdomains
|
||||
for subitem in os.listdir(path):
|
||||
subpath = os.path.join(path, subitem)
|
||||
if os.path.isdir(subpath) and subitem.startswith("intel-rapl:"):
|
||||
try:
|
||||
with open(os.path.join(subpath, "name"), "r") as f:
|
||||
subname = f.read().strip()
|
||||
domains[f"{name}:{subname}"] = {
|
||||
"path": subpath,
|
||||
"energy_file": os.path.join(subpath, "energy_uj"),
|
||||
"max_energy": self._read_max_energy(subpath),
|
||||
"last_energy": None,
|
||||
"last_time": None
|
||||
}
|
||||
except:
|
||||
continue
|
||||
|
||||
for domain in domains:
|
||||
self.power_data[domain] = deque(maxlen=100)
|
||||
|
||||
return domains
|
||||
|
||||
def _read_max_energy(self, path):
|
||||
try:
|
||||
with open(os.path.join(path, "max_energy_range_uj"), "r") as f:
|
||||
return int(f.read().strip())
|
||||
except:
|
||||
return 2**32
|
||||
|
||||
def _read_energy(self, domain):
|
||||
try:
|
||||
with open(self.domains[domain]["energy_file"], "r") as f:
|
||||
return int(f.read().strip())
|
||||
except:
|
||||
return None
|
||||
|
||||
def update_power(self):
|
||||
current_time = time.time()
|
||||
|
||||
for domain in self.domains:
|
||||
energy = self._read_energy(domain)
|
||||
if energy is None:
|
||||
continue
|
||||
|
||||
domain_info = self.domains[domain]
|
||||
|
||||
if domain_info["last_energy"] is not None:
|
||||
# Handle wraparound
|
||||
if energy < domain_info["last_energy"]:
|
||||
energy_diff = (domain_info["max_energy"] - domain_info["last_energy"]) + energy
|
||||
else:
|
||||
energy_diff = energy - domain_info["last_energy"]
|
||||
|
||||
time_diff = current_time - domain_info["last_time"]
|
||||
|
||||
if time_diff > 0 and energy_diff > 0:
|
||||
# Convert from microjoules to watts
|
||||
power = (energy_diff / 1e6) / time_diff
|
||||
self.power_data[domain].append(power)
|
||||
elif time_diff > 0:
|
||||
# No energy change, append last known power or 0
|
||||
if len(self.power_data[domain]) > 0:
|
||||
self.power_data[domain].append(self.power_data[domain][-1])
|
||||
else:
|
||||
self.power_data[domain].append(0.0)
|
||||
|
||||
domain_info["last_energy"] = energy
|
||||
domain_info["last_time"] = current_time
|
||||
|
||||
self.timestamps.append(current_time)
|
||||
|
||||
def get_current_power(self):
|
||||
result = {}
|
||||
for domain in self.domains:
|
||||
if len(self.power_data[domain]) > 0:
|
||||
result[domain] = self.power_data[domain][-1]
|
||||
else:
|
||||
result[domain] = 0
|
||||
return result
|
||||
|
||||
def get_power_history(self):
|
||||
return {domain: list(self.power_data[domain]) for domain in self.domains}
|
||||
|
||||
def plot_power_history(self, save_path=None, show=True):
|
||||
"""Plot power consumption history for all domains"""
|
||||
fig, ax = plt.subplots(figsize=(12, 8))
|
||||
|
||||
# Get timestamps relative to start
|
||||
if len(self.timestamps) < 2:
|
||||
print("Not enough data to plot")
|
||||
return
|
||||
|
||||
start_time = self.timestamps[0]
|
||||
time_points = [(t - start_time) for t in self.timestamps]
|
||||
|
||||
# Plot each domain
|
||||
for domain in self.domains:
|
||||
if len(self.power_data[domain]) > 0:
|
||||
# Ensure we have matching lengths
|
||||
data_len = min(len(time_points), len(self.power_data[domain]))
|
||||
ax.plot(time_points[:data_len],
|
||||
list(self.power_data[domain])[:data_len],
|
||||
label=domain, linewidth=2)
|
||||
|
||||
ax.set_xlabel('Time (seconds)', fontsize=12)
|
||||
ax.set_ylabel('Power (Watts)', fontsize=12)
|
||||
ax.set_title('System Power Consumption Over Time', fontsize=14)
|
||||
ax.grid(True, alpha=0.3)
|
||||
ax.legend()
|
||||
|
||||
plt.tight_layout()
|
||||
|
||||
if save_path:
|
||||
plt.savefig(save_path, dpi=300, bbox_inches='tight')
|
||||
|
||||
if show:
|
||||
plt.show()
|
||||
|
||||
return fig
|
||||
|
||||
class EnergyLogger:
|
||||
def __init__(self, output_format="csv"):
|
||||
self.monitor = RAPLEnergyMonitor()
|
||||
self.output_format = output_format
|
||||
self.start_time = time.time()
|
||||
self.log_data = []
|
||||
|
||||
def log_sample(self):
|
||||
self.monitor.update_power()
|
||||
current_power = self.monitor.get_current_power()
|
||||
|
||||
sample = {
|
||||
"timestamp": datetime.now().isoformat(),
|
||||
"elapsed_seconds": time.time() - self.start_time,
|
||||
"total_power": sum(current_power.values())
|
||||
}
|
||||
|
||||
for domain, power in current_power.items():
|
||||
sample[f"power_{domain}"] = power
|
||||
|
||||
self.log_data.append(sample)
|
||||
return sample
|
||||
|
||||
def save_csv(self, filename):
|
||||
if not self.log_data:
|
||||
return
|
||||
|
||||
with open(filename, 'w', newline='') as f:
|
||||
writer = csv.DictWriter(f, fieldnames=self.log_data[0].keys())
|
||||
writer.writeheader()
|
||||
writer.writerows(self.log_data)
|
||||
|
||||
def save_json(self, filename):
|
||||
with open(filename, 'w') as f:
|
||||
json.dump(self.log_data, f, indent=2)
|
||||
|
||||
def save(self, filename=None):
|
||||
if filename is None:
|
||||
filename = f"energy_log_{datetime.now().strftime('%Y%m%d_%H%M%S')}"
|
||||
|
||||
if self.output_format == "csv":
|
||||
self.save_csv(f"{filename}.csv")
|
||||
else:
|
||||
self.save_json(f"{filename}.json")
|
||||
|
||||
return filename
|
||||
|
||||
def plot_log_data(self, save_path=None, show=True):
|
||||
"""Plot logged energy data"""
|
||||
if not self.log_data:
|
||||
print("No data to plot")
|
||||
return
|
||||
|
||||
fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(12, 10))
|
||||
|
||||
# Extract data
|
||||
timestamps = [sample['elapsed_seconds'] for sample in self.log_data]
|
||||
total_power = [sample['total_power'] for sample in self.log_data]
|
||||
|
||||
# Plot total power
|
||||
ax1.plot(timestamps, total_power, 'b-', linewidth=2, label='Total Power')
|
||||
ax1.set_xlabel('Time (seconds)', fontsize=12)
|
||||
ax1.set_ylabel('Power (Watts)', fontsize=12)
|
||||
ax1.set_title('Total System Power Consumption', fontsize=14)
|
||||
ax1.grid(True, alpha=0.3)
|
||||
ax1.legend()
|
||||
|
||||
# Plot individual domains
|
||||
domain_names = [key for key in self.log_data[0].keys()
|
||||
if key.startswith('power_') and key != 'power_']
|
||||
|
||||
for domain_key in domain_names:
|
||||
domain_power = [sample.get(domain_key, 0) for sample in self.log_data]
|
||||
domain_name = domain_key.replace('power_', '')
|
||||
ax2.plot(timestamps, domain_power, linewidth=2, label=domain_name)
|
||||
|
||||
ax2.set_xlabel('Time (seconds)', fontsize=12)
|
||||
ax2.set_ylabel('Power (Watts)', fontsize=12)
|
||||
ax2.set_title('Power Consumption by Domain', fontsize=14)
|
||||
ax2.grid(True, alpha=0.3)
|
||||
ax2.legend()
|
||||
|
||||
plt.tight_layout()
|
||||
|
||||
if save_path:
|
||||
plt.savefig(save_path, dpi=300, bbox_inches='tight')
|
||||
|
||||
if show:
|
||||
plt.show()
|
||||
|
||||
return fig
|
||||
|
||||
def monitor_realtime(duration=60, visualize=False):
|
||||
"""Real-time monitoring with optional visualization"""
|
||||
if visualize:
|
||||
return monitor_realtime_visual(duration)
|
||||
|
||||
print("Real-time Energy Monitor")
|
||||
print("=" * 50)
|
||||
|
||||
try:
|
||||
monitor = RAPLEnergyMonitor()
|
||||
print(f"Monitoring domains: {', '.join(monitor.domains.keys())}")
|
||||
print(f"Duration: {duration} seconds")
|
||||
print("=" * 50)
|
||||
|
||||
start_time = time.time()
|
||||
|
||||
while time.time() - start_time < duration:
|
||||
monitor.update_power()
|
||||
power = monitor.get_current_power()
|
||||
|
||||
# Clear line and print current values
|
||||
print("\r", end="")
|
||||
print(f"[{int(time.time() - start_time):3d}s] ", end="")
|
||||
|
||||
for domain, watts in power.items():
|
||||
print(f"{domain}: {watts:6.2f}W ", end="")
|
||||
|
||||
print(f"Total: {sum(power.values()):6.2f}W", end="", flush=True)
|
||||
|
||||
time.sleep(0.1)
|
||||
|
||||
print("\n" + "=" * 50)
|
||||
print("Monitoring complete!")
|
||||
|
||||
except RuntimeError as e:
|
||||
print(f"Error: {e}")
|
||||
except KeyboardInterrupt:
|
||||
print("\n\nMonitoring stopped by user.")
|
||||
|
||||
def monitor_realtime_visual(duration=60):
|
||||
"""Real-time monitoring with live plotting"""
|
||||
plt.ion()
|
||||
fig, (ax1, ax2) = plt.subplots(2, 1, figsize=(10, 8))
|
||||
|
||||
try:
|
||||
monitor = RAPLEnergyMonitor()
|
||||
domains = list(monitor.domains.keys())
|
||||
|
||||
# Initialize plot lines
|
||||
lines1 = {}
|
||||
lines2 = []
|
||||
|
||||
# Setup total power plot
|
||||
ax1.set_xlabel('Time (seconds)')
|
||||
ax1.set_ylabel('Power (Watts)')
|
||||
ax1.set_title('Total System Power Consumption')
|
||||
ax1.grid(True, alpha=0.3)
|
||||
lines1['total'], = ax1.plot([], [], 'b-', linewidth=2, label='Total Power')
|
||||
ax1.legend()
|
||||
|
||||
# Setup domain power plot
|
||||
ax2.set_xlabel('Time (seconds)')
|
||||
ax2.set_ylabel('Power (Watts)')
|
||||
ax2.set_title('Power Consumption by Domain')
|
||||
ax2.grid(True, alpha=0.3)
|
||||
|
||||
for i, domain in enumerate(domains):
|
||||
line, = ax2.plot([], [], linewidth=2, label=domain)
|
||||
lines2.append(line)
|
||||
ax2.legend()
|
||||
|
||||
# Data storage
|
||||
times = []
|
||||
total_powers = []
|
||||
domain_powers = {domain: [] for domain in domains}
|
||||
|
||||
start_time = time.time()
|
||||
|
||||
print(f"Monitoring for {duration} seconds... Press Ctrl+C to stop early.")
|
||||
|
||||
while time.time() - start_time < duration:
|
||||
monitor.update_power()
|
||||
power = monitor.get_current_power()
|
||||
|
||||
# Update data
|
||||
current_time = time.time() - start_time
|
||||
times.append(current_time)
|
||||
total_powers.append(sum(power.values()))
|
||||
|
||||
for domain in domains:
|
||||
domain_powers[domain].append(power.get(domain, 0))
|
||||
|
||||
# Update plots
|
||||
lines1['total'].set_data(times, total_powers)
|
||||
ax1.relim()
|
||||
ax1.autoscale_view()
|
||||
|
||||
for i, domain in enumerate(domains):
|
||||
lines2[i].set_data(times, domain_powers[domain])
|
||||
ax2.relim()
|
||||
ax2.autoscale_view()
|
||||
|
||||
plt.draw()
|
||||
plt.pause(0.05)
|
||||
|
||||
plt.ioff()
|
||||
|
||||
# Save final plot
|
||||
save_path = f"energy_plot_{datetime.now().strftime('%Y%m%d_%H%M%S')}.png"
|
||||
plt.savefig(save_path, dpi=300, bbox_inches='tight')
|
||||
print(f"\nPlot saved to: {save_path}")
|
||||
|
||||
# Show final plot
|
||||
plt.show()
|
||||
|
||||
except RuntimeError as e:
|
||||
print(f"Error: {e}")
|
||||
except KeyboardInterrupt:
|
||||
print("\n\nMonitoring stopped by user.")
|
||||
plt.ioff()
|
||||
plt.close()
|
||||
|
||||
def main():
|
||||
import argparse
|
||||
|
||||
parser = argparse.ArgumentParser(description="Monitor system energy consumption")
|
||||
parser.add_argument("-d", "--duration", type=int, default=60,
|
||||
help="Duration to monitor in seconds (default: 60)")
|
||||
parser.add_argument("-l", "--log", action="store_true",
|
||||
help="Log data to file instead of real-time display")
|
||||
parser.add_argument("-i", "--interval", type=float, default=1.0,
|
||||
help="Sampling interval for logging (default: 1.0)")
|
||||
parser.add_argument("-f", "--format", choices=["csv", "json"], default="csv",
|
||||
help="Output format for logging (default: csv)")
|
||||
parser.add_argument("-o", "--output", type=str,
|
||||
help="Output filename for logging")
|
||||
parser.add_argument("-v", "--visualize", action="store_true",
|
||||
help="Enable real-time visualization")
|
||||
parser.add_argument("-p", "--plot", type=str,
|
||||
help="Plot saved data from CSV/JSON file")
|
||||
|
||||
args = parser.parse_args()
|
||||
|
||||
# Handle plotting existing data
|
||||
if args.plot:
|
||||
print(f"Loading data from: {args.plot}")
|
||||
|
||||
if args.plot.endswith('.csv'):
|
||||
# Load CSV data
|
||||
import pandas as pd
|
||||
df = pd.read_csv(args.plot)
|
||||
log_data = df.to_dict('records')
|
||||
elif args.plot.endswith('.json'):
|
||||
# Load JSON data
|
||||
with open(args.plot, 'r') as f:
|
||||
log_data = json.load(f)
|
||||
else:
|
||||
print("Error: Plot file must be .csv or .json")
|
||||
return
|
||||
|
||||
# Create a temporary logger to use its plotting method
|
||||
logger = EnergyLogger()
|
||||
logger.log_data = log_data
|
||||
|
||||
plot_path = args.plot.rsplit('.', 1)[0] + '_plot.png'
|
||||
logger.plot_log_data(save_path=plot_path)
|
||||
print(f"Plot saved to: {plot_path}")
|
||||
return
|
||||
|
||||
if args.log:
|
||||
# Logging mode
|
||||
print(f"Starting energy logging for {args.duration} seconds...")
|
||||
print(f"Sampling interval: {args.interval} seconds")
|
||||
print(f"Output format: {args.format}")
|
||||
|
||||
try:
|
||||
logger = EnergyLogger(output_format=args.format)
|
||||
|
||||
start_time = time.time()
|
||||
sample_count = 0
|
||||
|
||||
while time.time() - start_time < args.duration:
|
||||
sample = logger.log_sample()
|
||||
sample_count += 1
|
||||
|
||||
print(f"\rSamples: {sample_count} | Total Power: {sample['total_power']:.2f} W",
|
||||
end='', flush=True)
|
||||
|
||||
time.sleep(args.interval)
|
||||
|
||||
print("\n\nSaving data...")
|
||||
filename = logger.save(args.output)
|
||||
print(f"Data saved to: {filename}.{args.format}")
|
||||
|
||||
# Print summary
|
||||
avg_power = sum(s['total_power'] for s in logger.log_data) / len(logger.log_data)
|
||||
print(f"\nSummary:")
|
||||
print(f" Total samples: {len(logger.log_data)}")
|
||||
print(f" Average power: {avg_power:.2f} W")
|
||||
print(f" Total energy: {avg_power * args.duration / 3600:.4f} Wh")
|
||||
|
||||
# Generate plot if visualization is enabled
|
||||
if args.visualize:
|
||||
plot_filename = (args.output or filename) + "_plot.png"
|
||||
logger.plot_log_data(save_path=plot_filename)
|
||||
print(f" Plot saved to: {plot_filename}")
|
||||
|
||||
except RuntimeError as e:
|
||||
print(f"Error: {e}")
|
||||
except KeyboardInterrupt:
|
||||
print("\n\nLogging interrupted. Saving partial data...")
|
||||
if 'logger' in locals():
|
||||
filename = logger.save(args.output)
|
||||
print(f"Partial data saved to: {filename}.{args.format}")
|
||||
else:
|
||||
# Real-time monitoring mode
|
||||
monitor_realtime(args.duration, visualize=args.visualize)
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
166
src/48-energy/energy_monitor_traditional.sh
Executable file
166
src/48-energy/energy_monitor_traditional.sh
Executable file
@@ -0,0 +1,166 @@
|
||||
#!/bin/bash
|
||||
# Traditional energy monitoring script using /proc filesystem
|
||||
# This script monitors CPU usage and estimates energy consumption
|
||||
|
||||
# Default values
|
||||
DURATION=0
|
||||
CPU_POWER=15.0 # Default 15W per CPU
|
||||
VERBOSE=0
|
||||
INTERVAL=0.1 # Sampling interval in seconds
|
||||
|
||||
# Parse command line arguments
|
||||
while getopts "vd:p:i:" opt; do
|
||||
case $opt in
|
||||
v) VERBOSE=1 ;;
|
||||
d) DURATION=$OPTARG ;;
|
||||
p) CPU_POWER=$OPTARG ;;
|
||||
i) INTERVAL=$OPTARG ;;
|
||||
?) echo "Usage: $0 [-v] [-d duration] [-p power_watts] [-i interval]"
|
||||
exit 1 ;;
|
||||
esac
|
||||
done
|
||||
|
||||
echo "Traditional Energy Monitor Started..."
|
||||
echo "CPU Power: ${CPU_POWER}W"
|
||||
echo "Sampling Interval: ${INTERVAL}s"
|
||||
[ $DURATION -gt 0 ] && echo "Duration: ${DURATION}s"
|
||||
echo ""
|
||||
|
||||
# Get number of CPUs
|
||||
NUM_CPUS=$(nproc)
|
||||
|
||||
# Associative arrays to store data
|
||||
declare -A prev_cpu_time
|
||||
declare -A prev_total_time
|
||||
declare -A process_energy
|
||||
declare -A process_runtime
|
||||
declare -A process_comm
|
||||
|
||||
# Function to read CPU stats
|
||||
read_cpu_stats() {
|
||||
local cpu_line
|
||||
cpu_line=$(grep "^cpu " /proc/stat)
|
||||
echo "$cpu_line" | awk '{print $2+$3+$4+$5+$6+$7+$8}'
|
||||
}
|
||||
|
||||
# Function to read process stats
|
||||
read_process_stats() {
|
||||
local pid=$1
|
||||
if [ -f "/proc/$pid/stat" ]; then
|
||||
# Get process name
|
||||
local comm=$(cat /proc/$pid/comm 2>/dev/null || echo "unknown")
|
||||
process_comm[$pid]="$comm"
|
||||
|
||||
# Get CPU time (user + system time in clock ticks)
|
||||
local cpu_time=$(awk '{print $14 + $15}' /proc/$pid/stat 2>/dev/null || echo 0)
|
||||
echo "$cpu_time"
|
||||
else
|
||||
echo "0"
|
||||
fi
|
||||
}
|
||||
|
||||
# Get clock ticks per second
|
||||
CLK_TCK=$(getconf CLK_TCK)
|
||||
|
||||
# Initialize start time
|
||||
start_time=$(date +%s)
|
||||
sample_count=0
|
||||
|
||||
# Main monitoring loop
|
||||
while true; do
|
||||
# Get current total CPU time
|
||||
total_cpu_time=$(read_cpu_stats)
|
||||
|
||||
# Get list of all processes
|
||||
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
|
||||
if [ -d "/proc/$pid" ]; then
|
||||
current_cpu_time=$(read_process_stats $pid)
|
||||
|
||||
# Calculate delta if we have previous data
|
||||
if [ -n "${prev_cpu_time[$pid]}" ]; then
|
||||
delta_ticks=$((current_cpu_time - prev_cpu_time[$pid]))
|
||||
|
||||
if [ $delta_ticks -gt 0 ]; then
|
||||
# Convert ticks to seconds
|
||||
delta_seconds=$(echo "scale=6; $delta_ticks / $CLK_TCK" | bc)
|
||||
|
||||
# Calculate energy (Joules = Watts * seconds)
|
||||
energy=$(echo "scale=6; $CPU_POWER * $delta_seconds / $NUM_CPUS" | bc)
|
||||
|
||||
# Accumulate energy
|
||||
if [ -n "${process_energy[$pid]}" ]; then
|
||||
process_energy[$pid]=$(echo "scale=6; ${process_energy[$pid]} + $energy" | bc)
|
||||
process_runtime[$pid]=$(echo "scale=6; ${process_runtime[$pid]} + $delta_seconds" | bc)
|
||||
else
|
||||
process_energy[$pid]=$energy
|
||||
process_runtime[$pid]=$delta_seconds
|
||||
fi
|
||||
|
||||
if [ $VERBOSE -eq 1 ]; then
|
||||
printf "%-16s pid=%-6d runtime=%.3fs energy=%.6fJ\n" \
|
||||
"${process_comm[$pid]}" "$pid" "$delta_seconds" "$energy"
|
||||
fi
|
||||
fi
|
||||
fi
|
||||
|
||||
prev_cpu_time[$pid]=$current_cpu_time
|
||||
fi
|
||||
done
|
||||
|
||||
# Clean up terminated processes
|
||||
for pid in "${!prev_cpu_time[@]}"; do
|
||||
if [ ! -d "/proc/$pid" ]; then
|
||||
unset prev_cpu_time[$pid]
|
||||
fi
|
||||
done
|
||||
|
||||
sample_count=$((sample_count + 1))
|
||||
|
||||
# Check if we should exit
|
||||
if [ $DURATION -gt 0 ]; then
|
||||
current_time=$(date +%s)
|
||||
elapsed=$((current_time - start_time))
|
||||
if [ $elapsed -ge $DURATION ]; then
|
||||
break
|
||||
fi
|
||||
fi
|
||||
|
||||
# Handle Ctrl+C through trap
|
||||
|
||||
# Sleep for interval
|
||||
sleep $INTERVAL
|
||||
done
|
||||
|
||||
# Print summary
|
||||
echo ""
|
||||
echo "=== Energy Usage Summary ==="
|
||||
printf "%-10s %-16s %-15s %-15s\n" "PID" "COMM" "Runtime (s)" "Energy (J)"
|
||||
printf "%-10s %-16s %-15s %-15s\n" "----------" "----------------" "---------------" "---------------"
|
||||
|
||||
total_energy=0
|
||||
total_runtime=0
|
||||
|
||||
# Sort by energy consumption
|
||||
for pid in $(for p in "${!process_energy[@]}"; do
|
||||
echo "$p ${process_energy[$p]}"
|
||||
done | sort -k2 -nr | head -20 | awk '{print $1}'); do
|
||||
if [ -n "${process_energy[$pid]}" ] && [ "${process_energy[$pid]}" != "0" ]; then
|
||||
printf "%-10d %-16s %-15.3f %-15.6f\n" \
|
||||
"$pid" "${process_comm[$pid]}" "${process_runtime[$pid]}" "${process_energy[$pid]}"
|
||||
|
||||
total_energy=$(echo "scale=6; $total_energy + ${process_energy[$pid]}" | bc)
|
||||
total_runtime=$(echo "scale=6; $total_runtime + ${process_runtime[$pid]}" | bc)
|
||||
fi
|
||||
done
|
||||
|
||||
echo ""
|
||||
echo "Total CPU time: ${total_runtime}s"
|
||||
echo "Total estimated energy: ${total_energy}J"
|
||||
echo "CPU power setting: ${CPU_POWER}W"
|
||||
echo "Samples collected: $sample_count"
|
||||
|
||||
# Trap Ctrl+C to clean exit
|
||||
cleanup() {
|
||||
echo -e "\nStopping energy monitor..."
|
||||
}
|
||||
trap cleanup INT
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 158 KiB |
@@ -1,56 +0,0 @@
|
||||
#!/usr/bin/env python3
|
||||
"""
|
||||
Test script to demonstrate energy monitor visualization features
|
||||
"""
|
||||
|
||||
import subprocess
|
||||
import sys
|
||||
import os
|
||||
|
||||
def test_visualization():
|
||||
print("Energy Monitor Visualization Test")
|
||||
print("=" * 50)
|
||||
|
||||
# Check if we can import matplotlib
|
||||
try:
|
||||
import matplotlib
|
||||
print("✓ matplotlib is installed")
|
||||
except ImportError:
|
||||
print("✗ matplotlib is not installed")
|
||||
print("Please install with: pip install matplotlib")
|
||||
return
|
||||
|
||||
# Test 1: Real-time monitoring with visualization
|
||||
print("\nTest 1: Real-time monitoring with visualization (10 seconds)")
|
||||
print("This will show a live updating plot of power consumption")
|
||||
cmd1 = [sys.executable, "energy_monitor.py", "-d", "10", "-v"]
|
||||
print(f"Running: {' '.join(cmd1)}")
|
||||
input("Press Enter to start...")
|
||||
subprocess.run(cmd1)
|
||||
|
||||
# Test 2: Logging with plot generation
|
||||
print("\n\nTest 2: Logging data and generating plot (15 seconds)")
|
||||
cmd2 = [sys.executable, "energy_monitor.py", "-l", "-d", "15", "-i", "0.5", "-v", "-o", "test_energy"]
|
||||
print(f"Running: {' '.join(cmd2)}")
|
||||
input("Press Enter to start...")
|
||||
subprocess.run(cmd2)
|
||||
|
||||
# Test 3: Plot from saved data
|
||||
print("\n\nTest 3: Plotting from saved CSV file")
|
||||
if os.path.exists("test_energy.csv"):
|
||||
cmd3 = [sys.executable, "energy_monitor.py", "-p", "test_energy.csv"]
|
||||
print(f"Running: {' '.join(cmd3)}")
|
||||
input("Press Enter to start...")
|
||||
subprocess.run(cmd3)
|
||||
else:
|
||||
print("No saved data file found from Test 2")
|
||||
|
||||
print("\n" + "=" * 50)
|
||||
print("Visualization tests complete!")
|
||||
print("\nUsage examples:")
|
||||
print(" Real-time monitoring with plot: python energy_monitor.py -v")
|
||||
print(" Log data and generate plot: python energy_monitor.py -l -v")
|
||||
print(" Plot from existing data: python energy_monitor.py -p data.csv")
|
||||
|
||||
if __name__ == "__main__":
|
||||
test_visualization()
|
||||
406
src/48-energy/能源监控系统详解.md
Normal file
406
src/48-energy/能源监控系统详解.md
Normal file
@@ -0,0 +1,406 @@
|
||||
# eBPF 能源监控系统详解
|
||||
|
||||
## 概述
|
||||
|
||||
本项目实现了一个基于 eBPF 的进程级 CPU 能耗监控工具。通过在内核空间捕获进程调度事件，精确计算每个进程的 CPU 使用时间，并估算其能源消耗。相比传统的基于 `/proc` 文件系统的监控方式，该方案具有更低的系统开销和更高的监控精度。
|
||||
|
||||
## 系统架构
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ 用户空间 │
|
||||
│ ┌─────────────────────────────────────────────────────┐ │
|
||||
│ │ energy_monitor (用户态程序) │ │
|
||||
│ │ - 加载 eBPF 程序 │ │
|
||||
│ │ - 接收内核事件 │ │
|
||||
│ │ - 计算能耗并展示 │ │
|
||||
│ └──────────────────┬──────────────────────────────────┘ │
|
||||
│ │ Ring Buffer │
|
||||
└─────────────────────┼───────────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────┼───────────────────────────────────────┐
|
||||
│ ▼ 内核空间 │
|
||||
│ ┌─────────────────────────────────────────────────────┐ │
|
||||
│ │ energy_monitor.bpf.c (eBPF 程序) │ │
|
||||
│ │ - 挂载到调度器跟踪点 │ │
|
||||
│ │ - 记录进程运行时间 │ │
|
||||
│ │ - 发送事件到用户空间 │ │
|
||||
│ └─────────────────────────────────────────────────────┘ │
|
||||
│ ▲ │
|
||||
│ │ │
|
||||
│ ┌─────────────────┴────────────────────────────────────┐ │
|
||||
│ │ Linux 调度器 │ │
|
||||
│ │ - sched_switch (进程切换) │ │
|
||||
│ │ - sched_process_exit (进程退出) │ │
|
||||
│ └─────────────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## 核心组件详解
|
||||
|
||||
### 1. 数据结构定义 (energy_monitor.h)
|
||||
|
||||
```c
|
||||
struct energy_event {
|
||||
__u64 ts; // 时间戳（纳秒）
|
||||
__u32 cpu; // CPU 编号
|
||||
__u32 pid; // 进程 ID
|
||||
__u64 runtime_ns; // 运行时间（纳秒）
|
||||
char comm[16]; // 进程名称
|
||||
};
|
||||
```
|
||||
|
||||
这个结构体定义了内核向用户空间传递的事件数据格式，包含了计算能耗所需的所有信息。
|
||||
|
||||
### 2. eBPF 内核程序 (energy_monitor.bpf.c)
|
||||
|
||||
#### 2.1 核心数据结构
|
||||
|
||||
```c
|
||||
// 记录进程开始运行的时间
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 8192);
|
||||
__type(key, pid_t);
|
||||
__type(value, u64);
|
||||
} time_lookup SEC(".maps");
|
||||
|
||||
// 累计进程运行时间
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_PERCPU_HASH);
|
||||
__uint(max_entries, 8192);
|
||||
__type(key, pid_t);
|
||||
__type(value, u64);
|
||||
} runtime_lookup SEC(".maps");
|
||||
|
||||
// 环形缓冲区，用于传递事件
|
||||
struct {
|
||||
__uint(type, BPF_MAP_TYPE_RINGBUF);
|
||||
__uint(max_entries, 256 * 1024);
|
||||
} rb SEC(".maps");
|
||||
```
|
||||
|
||||
**关键设计决策：**
|
||||
- 使用 `PERCPU_HASH` 类型的 map 避免多核并发访问时的锁竞争
|
||||
- 环形缓冲区大小设为 256KB，平衡内存使用和事件丢失风险
|
||||
|
||||
#### 2.2 进程切换处理逻辑
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_switch")
|
||||
int handle_switch(struct trace_event_raw_sched_switch *ctx)
|
||||
{
|
||||
u64 ts = bpf_ktime_get_ns();
|
||||
pid_t prev_pid = ctx->prev_pid;
|
||||
pid_t next_pid = ctx->next_pid;
|
||||
|
||||
// 1. 计算前一个进程的运行时间
|
||||
if (prev_pid != 0) { // 忽略 idle 进程
|
||||
u64 *start_ts = bpf_map_lookup_elem(&time_lookup, &prev_pid);
|
||||
if (start_ts) {
|
||||
u64 delta = ts - *start_ts;
|
||||
// 更新累计运行时间
|
||||
update_runtime(prev_pid, delta);
|
||||
// 发送事件到用户空间
|
||||
send_event(prev_pid, delta, ctx->prev_comm);
|
||||
}
|
||||
}
|
||||
|
||||
// 2. 记录下一个进程的开始时间
|
||||
if (next_pid != 0) {
|
||||
bpf_map_update_elem(&time_lookup, &next_pid, &ts, BPF_ANY);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**工作流程：**
|
||||
1. 当发生进程切换时，获取当前时间戳
|
||||
2. 计算被切换出去的进程运行了多长时间
|
||||
3. 更新该进程的累计运行时间
|
||||
4. 通过环形缓冲区发送事件给用户空间
|
||||
5. 记录新进程开始运行的时间
|
||||
|
||||
#### 2.3 优化的除法实现
|
||||
|
||||
```c
|
||||
static __always_inline u64 div_u64_safe(u64 dividend, u64 divisor)
|
||||
{
|
||||
if (divisor == 0)
|
||||
return 0;
|
||||
|
||||
// 使用位移操作优化除法
|
||||
if (divisor == 1000) {
|
||||
// 纳秒转微秒的快速路径
|
||||
return dividend >> 10; // 近似除以 1024
|
||||
}
|
||||
|
||||
// 通用除法实现（避免使用 / 操作符）
|
||||
u64 quotient = 0;
|
||||
u64 remainder = dividend;
|
||||
|
||||
#pragma unroll
|
||||
for (int i = 0; i < 64; i++) {
|
||||
if (remainder >= divisor) {
|
||||
remainder -= divisor;
|
||||
quotient++;
|
||||
} else {
|
||||
break;
|
||||
}
|
||||
}
|
||||
|
||||
return quotient;
|
||||
}
|
||||
```
|
||||
|
||||
**优化说明：**
|
||||
- eBPF 程序中不能直接使用除法操作
|
||||
- 对于常见的纳秒转微秒操作，使用位移近似
|
||||
- 其他情况使用循环减法实现
|
||||
|
||||
### 3. 用户空间程序 (energy_monitor.c)
|
||||
|
||||
#### 3.1 主程序流程
|
||||
|
||||
```c
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
// 1. 解析命令行参数
|
||||
parse_args(argc, argv);
|
||||
|
||||
// 2. 加载并附加 eBPF 程序
|
||||
struct energy_monitor_bpf *skel = energy_monitor_bpf__open_and_load();
|
||||
energy_monitor_bpf__attach(skel);
|
||||
|
||||
// 3. 设置环形缓冲区回调
|
||||
ring_buffer__new(bpf_map__fd(skel->maps.rb), handle_event, NULL);
|
||||
|
||||
// 4. 主循环：处理事件
|
||||
while (!exiting) {
|
||||
ring_buffer__poll(rb, 100); // 100ms 超时
|
||||
}
|
||||
|
||||
// 5. 输出能耗统计
|
||||
print_energy_summary();
|
||||
}
|
||||
```
|
||||
|
||||
#### 3.2 事件处理逻辑
|
||||
|
||||
```c
|
||||
static int handle_event(void *ctx, void *data, size_t data_sz)
|
||||
{
|
||||
struct energy_event *e = data;
|
||||
|
||||
// 累计进程运行时间
|
||||
struct process_info *info = get_or_create_process(e->pid);
|
||||
info->runtime_ns += e->runtime_ns;
|
||||
strcpy(info->comm, e->comm);
|
||||
|
||||
if (env.verbose) {
|
||||
printf("[%llu] PID %d (%s) 在 CPU %d 上运行了 %llu 纳秒\n",
|
||||
e->ts, e->pid, e->comm, e->cpu, e->runtime_ns);
|
||||
}
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
#### 3.3 能耗计算模型
|
||||
|
||||
```c
|
||||
static void print_energy_summary(void)
|
||||
{
|
||||
double cpu_power_per_core = env.cpu_power / get_nprocs();
|
||||
|
||||
for (each process) {
|
||||
double runtime_ms = process->runtime_ns / 1000000.0;
|
||||
double runtime_s = runtime_ms / 1000.0;
|
||||
|
||||
// 能量 (焦耳) = 功率 (瓦特) × 时间 (秒)
|
||||
double energy_j = cpu_power_per_core * runtime_s;
|
||||
double energy_mj = energy_j * 1000;
|
||||
|
||||
printf("PID %d (%s): 运行时间 %.2f ms, 能耗 %.2f mJ\n",
|
||||
process->pid, process->comm, runtime_ms, energy_mj);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**计算假设：**
|
||||
- CPU 功率恒定（默认 15W，可通过 -p 参数调整）
|
||||
- 功率在所有 CPU 核心间平均分配
|
||||
- 不考虑 CPU 频率变化和睡眠状态
|
||||
|
||||
### 4. 与传统监控方式的对比
|
||||
|
||||
#### 4.1 传统方式 (energy_monitor_traditional.sh)
|
||||
|
||||
```bash
|
||||
# 每 100ms 读取一次 /proc/stat
|
||||
while true; do
|
||||
# 读取系统 CPU 时间
|
||||
cpu_times=$(cat /proc/stat | grep "^cpu")
|
||||
|
||||
# 读取每个进程的 CPU 时间
|
||||
for pid in $(ls /proc/[0-9]*); do
|
||||
stat=$(cat /proc/$pid/stat 2>/dev/null)
|
||||
# 解析并计算差值
|
||||
done
|
||||
|
||||
sleep 0.1
|
||||
done
|
||||
```
|
||||
|
||||
**传统方式的问题：**
|
||||
- 固定采样间隔，可能错过短期进程
|
||||
- 频繁的文件系统访问带来高开销
|
||||
- 采样精度受限于采样频率
|
||||
|
||||
#### 4.2 性能对比
|
||||
|
||||
| 指标 | eBPF 方式 | 传统方式 |
|
||||
|------|-----------|----------|
|
||||
| 系统开销 | < 1% CPU | 5-10% CPU |
|
||||
| 采样精度 | 纳秒级 | 毫秒级 |
|
||||
| 事件捕获 | 100% | 取决于采样率 |
|
||||
| 短期进程 | 完全捕获 | 可能遗漏 |
|
||||
| 实时性 | 实时 | 延迟 100ms+ |
|
||||
|
||||
### 5. 高级特性
|
||||
|
||||
#### 5.1 进程退出处理
|
||||
|
||||
```c
|
||||
SEC("tp/sched/sched_process_exit")
|
||||
int handle_exit(struct trace_event_raw_sched_process_template *ctx)
|
||||
{
|
||||
pid_t pid = ctx->pid;
|
||||
|
||||
// 清理该进程的跟踪数据
|
||||
bpf_map_delete_elem(&time_lookup, &pid);
|
||||
bpf_map_delete_elem(&runtime_lookup, &pid);
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
确保不会因为进程退出而导致内存泄漏。
|
||||
|
||||
#### 5.2 多核支持
|
||||
|
||||
使用 `PERCPU` 类型的 map，每个 CPU 核心维护独立的数据副本，避免锁竞争：
|
||||
|
||||
```c
|
||||
// 获取当前 CPU 的数据副本
|
||||
u64 *runtime = bpf_map_lookup_elem(&runtime_lookup, &pid);
|
||||
if (runtime) {
|
||||
__sync_fetch_and_add(runtime, delta); // 原子操作
|
||||
}
|
||||
```
|
||||
|
||||
## 使用场景
|
||||
|
||||
### 1. 应用性能分析
|
||||
|
||||
```bash
|
||||
# 监控特定应用的能耗
|
||||
./energy_monitor -v -d 60 # 监控 60 秒
|
||||
|
||||
# 结果示例：
|
||||
# PID 1234 (chrome): 运行时间 15234.56 ms, 能耗 57.13 mJ
|
||||
# PID 5678 (vscode): 运行时间 8456.23 ms, 能耗 31.71 mJ
|
||||
```
|
||||
|
||||
### 2. 容器能耗归因
|
||||
|
||||
结合容器 PID namespace，可以统计每个容器的能耗：
|
||||
|
||||
```bash
|
||||
# 获取容器内进程列表
|
||||
docker top <container_id> -o pid
|
||||
|
||||
# 监控并过滤特定 PID
|
||||
./energy_monitor | grep -E "PID (1234|5678|...)"
|
||||
```
|
||||
|
||||
### 3. 能效优化
|
||||
|
||||
通过对比优化前后的能耗数据，评估优化效果：
|
||||
|
||||
```bash
|
||||
# 优化前
|
||||
./energy_monitor -d 300 > before.log
|
||||
|
||||
# 进行代码优化...
|
||||
|
||||
# 优化后
|
||||
./energy_monitor -d 300 > after.log
|
||||
|
||||
# 对比分析
|
||||
./compare_results.py before.log after.log
|
||||
```
|
||||
|
||||
## 扩展可能性
|
||||
|
||||
### 1. 集成 RAPL 接口
|
||||
|
||||
```c
|
||||
// 读取实际 CPU 能耗
|
||||
static u64 read_rapl_energy(void)
|
||||
{
|
||||
int fd = open("/sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj", O_RDONLY);
|
||||
char buf[32];
|
||||
read(fd, buf, sizeof(buf));
|
||||
close(fd);
|
||||
return strtoull(buf, NULL, 10);
|
||||
}
|
||||
```
|
||||
|
||||
### 2. GPU 能耗监控
|
||||
|
||||
```c
|
||||
// 扩展 energy_event 结构
|
||||
struct energy_event {
|
||||
// ... 现有字段 ...
|
||||
__u64 gpu_time_ns; // GPU 使用时间
|
||||
__u32 gpu_id; // GPU 设备 ID
|
||||
};
|
||||
```
|
||||
|
||||
### 3. 机器学习模型
|
||||
|
||||
基于收集的数据训练能耗预测模型：
|
||||
|
||||
```python
|
||||
# 特征：CPU 利用率、内存访问模式、I/O 频率
|
||||
# 目标：预测未来 N 秒的能耗
|
||||
model = train_energy_prediction_model(historical_data)
|
||||
predicted_energy = model.predict(current_metrics)
|
||||
```
|
||||
|
||||
## 局限性与改进方向
|
||||
|
||||
### 当前局限性
|
||||
|
||||
1. **简化的能耗模型**：假设 CPU 功率恒定，未考虑动态频率调整
|
||||
2. **缺少硬件计数器**：未使用 CPU 性能计数器获取更精确的数据
|
||||
3. **单一能源类型**：仅考虑 CPU，未包含内存、磁盘、网络能耗
|
||||
|
||||
### 改进方向
|
||||
|
||||
1. **集成 perf_event**：使用硬件性能计数器提高精度
|
||||
2. **动态功率模型**：根据 CPU 频率和利用率动态调整功率估算
|
||||
3. **全系统能耗**：扩展到内存、I/O 等其他组件
|
||||
4. **实时可视化**：开发 Web 界面实时展示能耗数据
|
||||
|
||||
## 总结
|
||||
|
||||
本 eBPF 能源监控系统展示了如何利用现代 Linux 内核技术实现高效、精确的系统监控。通过在内核空间直接捕获调度事件，避免了传统监控方式的高开销，同时提供了纳秒级的时间精度。
|
||||
|
||||
该实现不仅是一个实用的工具，更是学习 eBPF 编程的优秀案例，涵盖了：
|
||||
- eBPF 程序开发的完整流程
|
||||
- 内核与用户空间的高效通信
|
||||
- 性能优化技巧
|
||||
- 实际应用场景
|
||||
|
||||
随着数据中心能效要求的不断提高，这类精细化的能耗监控工具将发挥越来越重要的作用。
|
||||
Reference in New Issue
Block a user