Treehouse: A Case For Carbon-Aware Datacenter Software | Summary

This article explains the key points of Treehouse: A Case For Carbon-Aware Datacenter Software.

• 2022-01-06 (arXiv)
• Anderson, Thomas, Belay, Adam, Chowdhury, Mosharaf, Cidon, Asaf, Zhang, Irene.
• University of Washington, MIT, University of Michigan, Columbia University, Microsoft Research
• Paper

Read this article in Korean

Summary

• Datacenter developers lack application-level tools to measure and reduce the energy and carbon costs of computing. Treehouse proposes software to reduce those costs while meeting application performance constraints, but reports no experimental comparison or measured reduction.
• The proposal combines energy provenance, accounting for an application’s direct and indirect energy use, with service-level agreements (SLAs), application performance constraints, and µfunctions, fine-grained execution units intended to use resources on demand. Its research agenda covers software overhead, interchangeable compute and memory, and energy-aware scheduling.
• The paper focuses on latency-sensitive workloads with deadlines of milliseconds or even single-digit microseconds, where shifting work to a distant datacenter or a later time is often impractical. The authors identify energy estimation, fast function startup, resource disaggregation, and scheduling speed as open problems.

1 Introduction

The authors cite estimates that datacenters consume 1–2% of worldwide electricity [31, 51] and argue that the end of Dennard scaling, under which energy efficiency improved as transistors shrank, has weakened automatic efficiency gains. They cite chip manufacturing as about one third of a modern datacenter’s lifecycle greenhouse gas emissions [27] and note constraints on renewable power for edge and on-premise deployments.

The schematic places rising application demand above a flattening efficiency curve and identifies measures that could narrow the gap; it does not report measured Treehouse savings.

2 Foundations for Energy-Aware Datacenter Software

The proposed foundations address three obstacles: developers cannot readily attribute energy to applications, operators lack application-specific performance constraints, and static bundles of compute, memory, and bandwidth waste resources under bursty demand. The paper notes that cost is an imperfect proxy for energy use, citing prior work in which field-programmable gate arrays (FPGAs), configurable accelerators, offer 10–70 times the energy efficiency of central processing units (CPUs) for computationally intensive applications [50].

2.1 Energy Provenance

Energy provenance includes energy used by an application itself and on its behalf by operating systems, storage, networks, and remote servers. The authors propose a supervised model trained and validated against laboratory measurements, using software-visible resource metrics and hardware topology; communication would carry provenance information, which could be combined with local power-generation carbon intensity [21].

2.2 Exposing Application-Level SLAs

An application-facing interface would expose performance constraints and tolerance for energy-saving changes, allowing systems to use available latency slack while meeting user requirements. The target is sub-second work, unlike batch jobs that can often be moved across locations or hours to use cleaner power [15–17, 34, 35, 42, 47].

The timeline distinguishes real-time workloads at microsecond and millisecond scales from interactive and batch workloads with more scheduling slack, motivating optimization within the same datacenter.

2.3 µfunctions

µfunctions are proposed as lightweight, interchangeable execution units detached from fixed virtual-machine or container resource bundles and intended to run on heterogeneous resources at microsecond timescales. Their proposed remote procedure call (RPC), a request to execute work on another system, interface would carry SLAs and energy or carbon budgets; the authors identify startup and invocation overhead as barriers, citing at least 125 milliseconds to start a Firecracker function environment [6].

Resource disaggregation would draw compute, memory, and storage from shared pools, reducing stranded capacity at the cost of added latency. Security, isolation, synchronization, fault tolerance, and the choice between adapting Linux and designing an operating system without POSIX compatibility remain open questions [40, 43, 57, 63].

2.4 Summary

The envisioned scheduler combines each µfunction’s energy provenance and SLA with hardware state, then selects resources and execution times to minimize energy while satisfying the SLA. This integration is an architectural proposal.

The diagram connects provenance, application constraints, and hardware state to a scheduler that assigns functions across separate compute and memory or storage pools.

3 Research Agenda

The research agenda develops the foundations through four directions: minimizing software bloat, interchanging compute resources, interchanging memory resources, and scheduling with energy and performance constraints.

3.1 Minimizing Software Bloat

A cited Google cluster profiling study attributes about 30% of cycles to common software building blocks and another 20% to the Linux kernel [32]. The authors propose streamlining the software stack, providing more direct access to input/output devices, and eventually offloading parts of the data path to efficient hardware.

3.2 Interchangeable Compute

The authors propose hybrid execution in which CPUs handle short bursts and FPGAs handle more stable, predictable work. A proposed intermediate representation, a common form convertible for different accelerators, would reduce the cost of maintaining multiple implementations while respecting performance constraints.

3.3 Interchangeable Memory

Dynamic random-access memory (DRAM), nonvolatile memory, solid-state drives (SSDs), and hard disk drives offer different energy and latency tradeoffs. The proposed system would place data according to timing constraints, access patterns, and granularity, using caching and prefetching to help meet SLAs within an energy budget [45].

The schematic shows a frontier between energy use and tail latency, with an energy budget and latency SLA defining constraints on acceptable memory choices.

3.4 Energy-Aware Scheduling

The authors suggest a multi-commodity flow formulation, representing applications and their resource choices as flows through compute and storage alternatives, with costs and capacity constraints encoding the energy-performance tradeoff [19, 30, 39]. Because placement may need to be decided within a few microseconds, they suggest approximation or reuse of previous results; deadline-based scheduling could also defer functions with more slack into later windows [25].

Three application flows connect to five interchangeable compute resources and data in DRAM or SSD, illustrating resource selection as a cost optimization problem at one instant.

4 Conclusion

Treehouse frames energy efficiency as a datacenter software design goal, combining developer visibility, explicit timing requirements, and lower-energy abstractions. The paper presents a research agenda and conceptual examples, so it does not establish achieved energy savings or SLA compliance.

Brief Thoughts

The proposal connects application requirements to hardware allocation and makes the energy-performance tradeoff explicit. Its practical value depends on accurate application-level accounting, microsecond-scale invocation and placement, and safe sharing of disaggregated resources.