Pack & cap: adaptive DVFS and thread packing under power caps

Reduce the power budget on a running server and performance goes up. That's not a paradox, it's what happens when you stop wasting power on the wrong configuration. The uncomfortable truth is that DVFS alone, the industry default for power-capped systems, leaves enormous efficiency on the table because it ignores a second control knob sitting right there in the OS: which cores the threads actually run on.

We built Pack & Cap to use both knobs together, adapting voltage-frequency settings and thread-core affinities simultaneously at runtime. Here's what we found.

Running four threads on four cores at a lower frequency is not the same as running four threads packed onto two cores with the other two sleeping. The second configuration draws less static power from the idle silicon, changes the memory access pattern, and can hit a lower total power draw without sacrificing as much throughput as simply dialing down the clock.

The subtler point: thread packing is dynamically reconfigurable with zero application modification. In Linux, you set thread-core affinities via thread IDs. No recompile, no runtime library, negligible overhead. Thread reduction, the alternative where you actually launch fewer threads, requires touching application code and can't be changed mid-execution gracefully. Packing wins on practicality even before you look at the performance numbers.

Before building the controller, we needed to understand whether thread packing and V-F setting choices actually matter, and how much they interact. We profiled all 13 PARSEC benchmarks across 9 voltage-frequency levels and 1, 2, or 4 thread configurations, measuring runtime, power, and energy across the first 100 billion retired micro-ops in the parallel phase.

The first result stopped us: in the unconstrained case, 4 threads always wins on both runtime and energy, regardless of V-F level. That seems obvious for runtime, but energy? We expected some workloads to prefer fewer threads for energy efficiency. They didn't. Four threads on four cores at the right frequency dominates. This tells you that any power-capped strategy that starts by reducing thread count is already fighting against the workload's natural efficiency point.

The energy-runtime tradeoff curves reveal why V-F selection is non-trivial even without thread packing. Canneal's optimal energy point sits at 2.13 GHz, not the highest frequency. Blackscholes hits its energy minimum at 2.53 GHz. These curves are convex-shaped but the minima are workload-specific and non-obvious from first principles.

Next we asked: does packing four threads onto fewer cores actually behave differently from just running fewer threads? Across 117 comparison points, thread packing is 2.1% faster than thread reduction on a single core and 1.0% more power-hungry. The gap is small but consistent. More importantly, packing gives you a control knob you can change at runtime. Reduction doesn't.

Then we looked at what happens under power caps. We swept power constraints from ~110W to ~180W and plotted runtime against cap for each core-count configuration. The key finding: no single thread count dominates across the full range. At high power budgets, 4 cores wins. As the cap tightens, 2 cores or even 1 core becomes optimal. The efficient frontier across all power levels is a composite curve that requires switching core count as the budget changes. DVFS alone, which assumes all cores stay active, can't reach the lower-power points on this frontier at all.

Pack & Cap splits into two phases: offline learning and runtime control.

Offline, we collect performance counter readings, thermal sensor data, and power measurements while running each benchmark across all 27 operating points (9 V-F levels times 3 thread configurations). We compute feature ratios from these readings, forming a feature vector Phi(x), and label each observation with the optimal operating point for a given power constraint. A multinomial logistic regression classifier learns the mapping from features to optimal operating point. We use L1 regularization to find the most predictive subset of features automatically, which keeps the model compact and reduces overfitting. The result is a set of weight vectors, one per power constraint level, stored in lookup tables.

At runtime, the system reads performance counters and thermal sensors (no power meter needed), computes Phi(x), looks up the weight vector for the current power cap, and runs the MLR forward pass to get a probability distribution over operating points. The highest-probability point becomes the new V-F setting and thread-core affinity assignment. The controller then updates both knobs.

The absence of a runtime power meter is a deliberate design choice, not a limitation. Power meters add hardware cost and latency. Our classifier infers power state from counters and temperatures, which are universally available on modern processors.