Source-linked AI summary
A Technique for Load Shifting Low-latency Applications in Multi-Region Renewables Harvesting via SMT Core Pooling
Tharindu B. Hewage, Shashikant Ilager, Maria A. Rodriguez, Rajkumar Buyya
TL;DR
Cloud load shifting follows intermittent renewable availability but often excludes low-latency applications because WANs introduce variable latency. This paper combines SMT-based server pooling with VM scheduling to keep such workloads local, reducing offloading by 80% and p90-latency variation by 43.81%, with an 11.97% worst-case latency compromise.
Problem
Load shifting across regions often omits low-latency applications because WAN latency variance conflicts with their rigid performance constraints.
Method
A hardware-software co-design uses heterogeneous SMT server pools, core-level power management, and VM scheduling to maintain static logical-core capacity and keep low-latency VMs local.
Results
80% reduction in offloading low-latency VMs and 43.81% reduction in coefficient of variation of p90 latency were achieved, with an 11.97% worst-case latency compromise from SMT cores.
Takeaways & Limitations
The technique accommodates low-latency workloads in renewable-aware load shifting while reducing WAN-related disruption and retaining best-effort shifting flexibility.
Abstract
from arXiv · showhide
Load shifting across geographic regions to chase intermittent renewable energy availability is commonly used in reducing cloud infrastructure carbon footprint. However, it often omits low-latency applications due to high latency variances of wide area networks (WAN) that interconnect regions. This paper addresses accommodating low-latency applications into load shifting by minimizing their shifting across the WAN. We propose a technique using a hardware-software co-design approach. At the hardware level, we conduct server load matching over renewables supply peaks and valleys by deep idling physical cores in two otherwise identical server pools, with one enabling simultaneous multi-threading (SMT) in CPUs. In return, we achieve a static set of logical cores amidst energy supply dynamics, reducing the probability of workload shifting. At the software level, we efficiently chase the static set of cores for low-latency applications within regions while prioritizing best-effort applications to accommodate shifting requirements across WANs. Our approach exploits the lower performance compromise of SMT cores due to their hardware multi-threading. We implement the proposed technique with OpenStack and CPU idle states and evaluate its performance on a real experimental testbed with Azure VM arrival traces. Results show an 80% reduction in offloading low-latency VMs and a 43.81% reduction in coefficient of variation of p90 end-user latency while having a worst-case latency compromise of 11.97% due to SMT cores.
I. INTRODUCTION
Cloud load shifting can reduce carbon emissions by following renewable-energy availability, but WAN-induced latency variance makes low-latency workloads difficult to shift. The paper proposes hardware-software coordination to retain these workloads within local regions while adapting server capacity to renewable supply.
- Low-latency applications are difficult to include in load shifting because migrations across WANs expose them to high latency variance and rigid latency constraints.The motivation emphasizes minimizing workload shifting across the WAN while preserving application service quality.
- The technique maintains a static set of logical cores across renewable supply peaks and valleys using heterogeneous SMT and non-SMT server pools.Physical cores are deep-idled during supply valleys, while SMT provides additional logical cores in one pool.
- The software layer chases the static core set within the local region and prioritizes best-effort workloads for shifting across WANs.This division limits WAN movement for latency-sensitive workloads while accommodating renewable-driven capacity changes.
- 80% reduction in offloading low-latency VMs is targeted by the proposed localized load-shifting technique.The evaluation uses an experimental cloud region, OpenStack, CPU idle states, and Azure workload traces.
- The approach evaluates low-latency performance using Cyclictest on an experimental testbed with SMT server pooling and local networking.The setup uses HP ProLiant servers with 12-core Intel Xeon Silver CPUs, Azure VM arrivals, and ELIA solar dynamics.
II. BACKGROUND AND MOTIVATION
Renewable-aware load shifting across cloud regions must reconcile dynamic server capacity and variable WAN latency with low-latency applications’ rigid latency requirements. The paper formulates this as maximizing VM latency performance while meeting dynamic server-capacity constraints.
- Dynamic server resource scaling problem in utilizing intermittent renewable energy availability across cloud regions: Cloud regions use geographically distributed infrastructure and intermittent renewables, creating spatially varying carbon intensity and dynamically changing server capacity.Stable grid sources provide baseline capacity, while renewable sources add peaks and valleys of available power.
- Challenges in accommodating low-latency applications for load shifting: Low-latency applications are difficult to shift because WAN routes have unpredictable latency that can violate their SLAs.Their rigid latency constraints make cross-region VM offloading problematic when renewable-driven resource down-scaling occurs.
- System model: The model represents workload placement across local and cross-region resources, with VM arrivals divided into low-latency and best-effort applications.WAN routes connecting regions are modeled as having varying latency performance.
- Dynamic server resource scaling model: Server capacity is modeled as Pcap(t) = Pgrid + Prnw(t), combining stable grid capacity with time-varying renewable capacity.The renewable component is represented as a two-level signal that can support peak server load when sufficient capacity is available.
- Problem formulation: The optimization objective is to maximize end-user latency performance of executed low-latency VMs over an interval ΔT while satisfying dynamic server-capacity scaling.WAN latency is aggregated from the latency Li(t) of each executed low-latency VM.
IV. LOAD SHIFTING FOR LOW-LATENCY APPLICATIONS WITH SMT CORE POOLING
The proposed technique combines core-level power management, SMT server pooling, and VM scheduling to preserve local capacity for low-latency VMs during renewable supply changes. It retains low-latency workloads within the local region while shifting best-effort workloads as needed.
- Hardware-software co-design: SMT pooling maintains a static set of logical cores across renewable supply dynamics by pairing heterogeneous server pools with core-level power management.The SMT pool doubles available logical cores through hardware multi-threading, while physical cores can be power-managed for changing supply.
- Load-shifting technique: The three-step design combines core-level power management, SMT pooling, and VM scheduling to retain low-latency VMs locally.Together, these mechanisms exploit hardware multi-threading to reduce low-latency workloads’ movement over the WAN.
- Load-shifting technique: The VM scheduling algorithm uses the static core set for low-latency applications and manages best-effort VMs to accommodate shifting requirements across regions.This design lowers the likelihood that already admitted low-latency VMs will be offloaded over the WAN.
A. Hardware-level logical core management
The hardware design maintains a static set of logical CPU cores across renewable supply peaks and valleys by combining deep idling with SMT across two server pools.
- A. Hardware-level logical core management: At low renewable supply, half of each server’s physical cores are placed into deep sleep to meet the reduced power cap.
- A. Hardware-level logical core management: At high renewable supply, all cores are awakened to use the available power capacity.
- A. Hardware-level logical core management: SMT pooling provides a static set of logical cores across renewable supply states by alternating which server pool supplies them.At peaks, the non-SMT pool supplies the static set; at valleys, the SMT pool does so after half the physical cores are deep-idled.
- A. Hardware-level logical core management: SMT is restricted to supply valleys because core oversubscription can affect low-latency VM performance.Using SMT only during valleys further reduces the performance impact, after which scheduling uses the static logical-core set.
B. Software-level VM scheduling algorithm
The scheduling algorithm places VMs according to latency criticality and renewable state, while transitioning between pools by offloading best-effort VMs and live-migrating low-latency VMs.
- B. Software-level VM scheduling algorithm: Incoming VM requests and the current renewable supply state determine placement decisions and server-pool management.
- B. Software-level VM scheduling algorithm: Low-latency VMs are placed in the non-SMT pool at renewable peaks but are not admitted during valleys.
- B. Software-level VM scheduling algorithm: During peak-to-valley transitions, best-effort VMs are offloaded from the SMT pool and low-latency VMs are live-migrated into it.The reverse transition offloads best-effort VMs from the non-SMT pool and migrates low-latency VMs back to the non-SMT pool.
- B. Software-level VM scheduling algorithm: The algorithm jointly manages VM placement and server pools to preserve fixed capacity for already admitted low-latency VMs.It uses live migration and best-effort VM offloading to improve low-latency service quality while utilizing SMT pooling.
V. IMPLEMENTATION
The technique is implemented in a real experimental cloud environment using CPU idle states, SMT pooling, and OpenStack-based VM scheduling.
- V. IMPLEMENTATION: Core-level power management and SMT pooling are implemented using Intel CPU idle-state features.
- V. IMPLEMENTATION: The VM scheduling algorithm is implemented at the cloud resource-management layer with OpenStack.
- V. IMPLEMENTATION: A per-server daemon exposes RESTful controls over CPU c-states and maintains half of the cores in deep idle when requested.
VI. PERFORMANCE EVALUATION
The performance evaluation measures the proposed technique experimentally, compares it with a state-of-the-art baseline, and analyzes the results.
- VI. PERFORMANCE EVALUATION: The evaluation experimentally measures the performance of the proposed technique.
- VI. PERFORMANCE EVALUATION: The experimental study includes an explicit comparison with a state-of-the-art baseline.
- VI. PERFORMANCE EVALUATION: The evaluation also analyzes the measured results in detail.
A. Experimental design and setup
The evaluation uses a real prototype multi-node cloud region with identical SMT and non-SMT server pools, each based on a 12-core Intel Xeon server.
- A. Experimental design and setup: The prototype cloud region allocates one identical HP ProLiant server to each SMT and non-SMT pool.Each server uses an Intel Xeon CPU with 12 physical cores.
1) Baselines::
The proposed technique is evaluated against Space-Shifting, using Azure VM packing data, ELIA solar dynamics, and measured cloud-region latency variation.
- 1) Baselines::: The primary baseline is Space-Shifting, which moves flexible workloads across cloud regions according to energy availability.The comparison evaluates how well each approach accommodates low-latency workloads.
- 1) Baselines::: Azure VM packing data, ELIA solar dynamics, and measured regional latency variation provide realistic workload, renewable-supply, and WAN-latency inputs.Azure traces are sampled and synthesized to match the experimental deployment.
- 1) Baselines::: Application latency measures performance inside low-latency VMs, while end-user latency measures the impact of shifting VMs across the WAN.Guest-operating-system latency is monitored with cyclictest for application-level measurement.
B. Results and Analysis
The evaluation examines latency on heterogeneous server pools, VM scheduling, and WAN effects, comparing the proposed technique with Space-Shift. It reports lower low-latency VM offloading and lower p90 latency variation, with a bounded SMT latency penalty.
- B. Results and Analysis: 11.97% higher mean latency occurs on SMT cores at 100% vCPU utilization, while both pools remain around 8 microseconds at 33% and 67% utilization.At full utilization, SMT packing reaches 10 microseconds versus about 9 microseconds on non-SMT cores.
- B. Results and Analysis: 80% reduction in offloaded low-latency VM events demonstrates that the proposed technique surpasses Space-Shift on retaining these VMs locally.The technique increases best-effort VM offloading while reducing low-latency VM offloading.
- B. Results and Analysis: WAN latency affects not-admitted VMs and partially affects offloaded VMs in the end-user latency evaluation.Figure 7 compares the p90 latency distributions of VMs.
- B. Results and Analysis: 43.81% reduction in the coefficient of variation of p90 latency lowers end-user latency variability relative to Space-Shift.The proposed technique has a coefficient of variation of 0.62, compared with 1.10 for Space-Shift.
VII. RELATED WORK
Prior renewable-cloud studies primarily shift flexible workloads across space or time, while this work targets low-latency applications by coordinating heterogeneous server pools and VM scheduling.
- Prior approaches commonly use geographical balancing, VM migration, workload admission, or capacity planning for flexible workloads that tolerate delayed execution.Examples include workloads able to withstand delays of up to 24 hours.
- WAN-aware load-shifting studies consider dynamic congestion or energy-related transfer costs but do not focus on low-latency applications.
- Power oversubscription approaches manage delivery changes by throttling server compute capabilities and dynamically scheduling VMs by priority.The cited limitation is that workload throttling can lead to non-ideal outcomes, though the supplied passage truncates the specific consequence.
- 80% reduction in offloading low-latency VMs is reported versus state-of-the-art space-shifting, alongside reduced latency variability.The technique is evaluated with Azure VM arrival traces on an experimental cloud region.