IM Engineer Study Notes
← Back to list
Computing & Embedded
#DVFS#전력관리#저전력설계#cpufreq#race-to-idle
Last updated · 2026-10-19

Dynamic Voltage and Frequency Scaling (DVFS)

1. Overview

Dynamic Voltage and Frequency Scaling (DVFS) is a power-management technique that adjusts the supply voltage and operating frequency together at run time to match the amount of work (load) a processor is performing, thereby minimizing power consumption and heat while still meeting the required performance. Its essence is "do not always run at top speed; run only as fast as is needed right now," and lowering voltage and frequency together is what distinguishes it from simple clock gating.

The background to DVFS is the power-density problem created by semiconductor process scaling. As the process shrank, more transistors could be integrated into the same area, but continually raising the clock caused power consumption per unit area to surge, and cooling hit its limit. The halt of the "clock race" in the mid-2000s and the turn to multicore was precisely because of this power wall, and from that point the paradigm shifted from "designs that squeeze out performance" to "designs that raise performance per watt." DVFS is the representative technique standing at the center of that shift.

Conceptually DVFS was proposed in low-power research in the late 1990s and began to be seriously adopted in commercial processors around 2000. Intel's SpeedStep, AMD's PowerNow!/Cool'n'Quiet, and Transmeta Crusoe's LongRun are early representative cases, and in the ARM camp it became a de facto standard technique as mobile spread. Initially the OS switched large steps slowly, but today it has grown refined to the point where hardware autonomously adjusts dozens of steps on a microsecond scale. Thus DVFS is a mature technology honed over more than twenty years, yet it is still evolving under new pressures such as process scaling and AI workloads.

The need for DVFS shows a different face depending on the operating environment. In battery devices such as smartphones and wearables, extending battery life is the top priority; in data centers the motive is cutting electricity and cooling bills and staying within rack power limits; and in embedded and automotive systems the direct reason is heat and reliability management. That is, DVFS is used in common across the whole spectrum from mobile to HPC, but it can be applied correctly only once one understands that the objective function each domain wants to optimize differs. Recently, as data-center power consumption has become a social issue and carbon-emission regulation has tightened, DVFS is being re-examined not merely for cost reduction but from a sustainability / green-computing viewpoint as well. The ability to perform the same computation with less energy is, in effect, a means of reducing the carbon footprint.

The basis for the effect DVFS targets lies in the dynamic-power equation of CMOS circuits. Dynamic power is roughly expressed as P_dyn ≈ α·C·V²·f, where α is the switching activity factor, C the load capacitance, V the supply voltage, and f the frequency. The fact that power is proportional to the square of voltage (V²) in this equation explains everything about DVFS. Lowering frequency alone reduces power only linearly, but because lowering frequency lets the circuit operate stably at a lower voltage, the voltage can be lowered together, and as a result power drops nearly cubically. As shown later, this "squared term" is exactly why DVFS is overwhelmingly more advantageous than simple frequency adjustment.

The features that distinguish DVFS from other power-saving means can be organized into three. The first is run-time adaptivity: it changes the operating point by looking at the load during execution, not at design time. The second is simultaneous adjustment of voltage and frequency: it does not separate the two, in order to obtain the squared effect above. The third is performance reversibility: unlike power gating, which turns a block completely off, performance can be restored at any time, making it suitable for cores that must always be running. Thanks to these three features, DVFS has become the default power-management means for general-purpose processors where momentary suspension is not allowed.

2. Operating Principle and Power Model

To understand DVFS properly, one must first distinguish where power is consumed. A processor's power consumption is broadly divided into dynamic power, which arises from switching, and static (leakage) power, which leaks merely because transistors are on. DVFS mainly targets dynamic power, but the fact that the newer the process, the larger the share of static power—so that DVFS alone has limits—is a key issue of modern power management.

flowchart TB
  subgraph TOT["Processor power consumption"]
    DYN["Dynamic power P_dyn ≈ α·C·V²·f"]
    STA["Static power P_static (leakage current)"]
  end
  DYN --> F["Lower frequency f and voltage V together"]
  F --> SAVE["Steep power drop from voltage-squared effect"]
  STA --> LEAK["Reduced only by cutting via sleep/power gating"]
  SAVE --> GOAL["Raise performance per watt while keeping required performance"]
  LEAK --> GOAL

Why static power becomes an ever-greater problem touches on the physics of process scaling. The finer the process, the more the transistor's threshold voltage must be lowered together to maintain speed, and as threshold voltage drops, the leakage current through transistors that should be off increases exponentially. As a result, in leading-edge processes at 10nm and below, the share of static power in total power has grown much larger than before, reducing the relative effect of DVFS, which cuts only dynamic power. This is the background to the grand principle of modern low-power design that "DVFS alone is not enough and must be combined with power gating and sleep states (C-states)."

As the figure above shows, DVFS is a means of pulling down the V²·f term, and leakage current must be handled by separate power gating. Here it is important why voltage and frequency must necessarily be adjusted together. Because a transistor's switching delay lengthens as voltage drops, lowering voltage also lowers the maximum frequency at which the circuit can operate stably. Therefore, for a given frequency there exists a minimum voltage that can sustain it, and chip makers prescribe these (frequency, voltage) safe combinations in advance as a discrete step table called P-states or OPPs (Operating Performance Points). DVFS does not use arbitrary values but moves among these verified steps.

The OPP table is written with a slight safety margin during chip characterization so as to withstand process-voltage-temperature (PVT) variation. For example, a certain mobile core has anywhere from five or six to dozens of steps, such as 1.05V at 2.4GHz, 0.90V at 1.8GHz, 0.75V at 1.0GHz. The finer the steps, the more precisely the load can be matched, but the more frequent the transitions and the more complex the control. The governor chooses, among these discrete steps, the lowest one that satisfies the current load, and this is the essential decision of DVFS control.

Let us gauge the magnitude of the power savings numerically. Suppose a core operates at 2.0GHz at 1.2V, then the load drops and it goes down to 1.0GHz at 0.9V. Since dynamic power is proportional to V²·f, (0.9/1.2)² × (1.0/2.0) ≈ 0.5625 × 0.5 ≈ 0.28, that is, about a 72% reduction. Had only the frequency been halved, power would have fallen by just 50%; by lowering the voltage too, a great deal more was saved. Thus frequency adjustment not accompanied by voltage lowering is like using only half of DVFS. Conversely, turbo boost, which raises performance, applies the same equation in reverse: it raises voltage to allow a higher frequency, squeezing out performance for a brief moment, but power and heat shoot up more than quadratically. That is why turbo is held only as long as the thermal budget allows, and is automatically withdrawn once temperature reaches a threshold. In this way DVFS performs bidirectional adjustment—power saving downward and momentary performance upward—on a single voltage-frequency axis.

There is also a principle to the order of changing voltage and frequency. When raising performance, raise voltage first to secure the headroom to sustain the target frequency, then raise frequency; when lowering, lower frequency first, then lower voltage. Reversing the order is because it creates a dangerous window of operating at a high frequency while voltage is insufficient, which can cause computation errors. Thus DVFS is not merely changing values but requires sequential control that accounts for voltage-stabilization wait time and PLL re-lock time, and this transition overhead is the basis for the "too-frequent transitions are a loss" constraint discussed later.

However, the pitfall of DVFS is that power (instantaneous consumption) and energy (power × time) are different. Lowering frequency reduces instantaneous power, but it takes more time to finish the same work, and during that time static power (leakage) keeps leaking. When the share of static power grows large in a newer process, a paradox arises in which running "slowly and long" uses even more total energy than "finishing fast and sleeping." This trade-off is the starting point of the race-to-idle debate discussed in the next section.

This distinction must always be made clear when evaluating DVFS. The optimal DVFS policy differs completely depending on whether the goal is to reduce total energy (J), as with data-center electricity bills; to lower instantaneous power (W), as with a battery device's momentary heat and lifetime; or to keep peak power below a certain value, as with a rack power limit. For example, if staying within a power cap is the goal, it is better to limit the maximum frequency itself even at some sacrifice of average performance, whereas if minimizing total energy is the goal, one must choose between race-to-idle and holding low voltage per workload. Confusing the target metric leads to a paradox of "power dropped but the electricity bill stayed the same."

3. Control Methods and Types

The performance and power effect of DVFS vary greatly with the control policy that decides "when and by how much to change voltage and frequency." Even on the same hardware, battery life and responsiveness differ noticeably depending on which governor is used, so the control policy is the key that decides the success or failure of a DVFS design. It can be divided into several types by the control agent and the basis of judgment, and the architecture figure below shows the control loop from load observation to voltage-frequency application. The core of this loop is that the PMIC/VRM in charge of voltage and the PLL in charge of frequency are physically separate, so the controller must coordinate the change order and the stabilization wait.

sequenceDiagram
  participant WL as "Workload (application)"
  participant OS as "OS governor (cpufreq)"
  participant PMIC as "Voltage regulator (PMIC/VRM)"
  participant CPU as "Processor core"
  WL->>OS: "Pass CPU utilization / scheduler signals"
  OS->>OS: "Decide target OPP (frequency/voltage)"
  OS->>PMIC: "Request target voltage setting"
  PMIC->>CPU: "Raise/lower supply voltage (await stabilization)"
  OS->>CPU: "Change clock frequency (PLL re-lock)"
  CPU-->>OS: "Change done / performance-counter feedback"
  Note over OS,CPU: "When raising, voltage first; when lowering, frequency first"

A. Classification by control agent

First, the OS software control method is the traditional one in which the operating system looks at CPU utilization and scheduler information to choose the frequency. Linux's cpufreq subsystem is representative, with performance (always highest), powersave (always lowest), ondemand/conservative (utilization-based reactive), and the modern schedutil governor. schedutil sets the frequency by adding about a 25% margin to the CFS/RT/DL/IRQ utilization signals aggregated by the scheduler, and in that it integrates the scheduler with power control, it reacts more accurately and faster than legacy timer-based governors.

The limit of OS control lies in the delay between observation and reaction. A timer-based governor such as ondemand looks at utilization every few tens of ms and adjusts the frequency, so it is prone to "lagging behind" burst loads like touch scrolling that strike and vanish within a few ms. It raises the frequency only after the load has ended, or belatedly lowers a frequency that was raised to match an already-finished load. Here is why schedutil receives the scheduler's utilization signal directly: it immediately reflects the utilization at the moment a task wakes, reducing reaction delay. Even so, the millisecond-scale delay of the software path cannot be fully eliminated, so the following hardware autonomous control emerged as a complement.

Second, the hardware autonomous control method has the chip's internal power-management unit adjust the frequency by itself on a microsecond scale far faster than the OS. Intel's Speed Shift (HWP, Hardware P-states) and AMD's CPPC correspond to this. The OS gives only a hint of the "desired performance range," and the hardware makes the actual frequency choice, eliminating the tens-of-milliseconds OS-intervention delay when load changes abruptly and raising both responsiveness and efficiency. The hardware also has the advantage of being able to make more accurate judgments faster, because it directly knows internal state the OS cannot see (each core's actual temperature, current, and activity rate). That said, there was a case in Linux 5.11 where reflecting HWP's target performance as-is led some workloads to reach maximum turbo too quickly and lose efficiency, so the mapping logic was re-tuned. This shows not that "the more you leave to hardware, the better," but that the division of roles between OS and hardware must be finely tuned. Since the OS knows the whole-system context (which task is important) and the hardware knows the physical present state, how the two pieces of information are combined is the crux of efficiency.

Third, heterogeneous / per-domain control is a method that splits one chip into multiple voltage-frequency domains and adjusts each independently. ARM's big.LITTLE / DynamIQ groups high-performance and high-efficiency cores, switching the core itself according to the nature of the work and controlling each core group with separate DVFS. Linux's EAS (Energy Aware Scheduling) refers to the power-performance model of each OPP to compute, at the scheduling stage, "on which core and at which frequency will placing this task minimize energy"; EAS is designed on the premise of the schedutil governor, where frequency follows utilization, so the two are strongly coupled.

The reason heterogeneous control matters is that even for the same work, energy efficiency differs several-fold depending on which core it runs on. Placing a light task like background synchronization or notifications on a high-performance core wastes power, while conversely confining a latency-sensitive task like user interaction to efficiency cores only makes response slow. EAS decides this placement automatically based on the power-performance model, but since it makes wrong choices if the model diverges from the actual chip, the model's accuracy governs the overall effect. That is, heterogeneous DVFS is an attempt to integrate "where to run (scheduling)" and "how fast to run (governing)" under a single energy objective function, and it is a key axis of modern mobile SoC power efficiency.

B. The race-to-idle strategy

Beneath the control policy lie two philosophies: "slowly and long" and "finish fast and sleep." Race-to-idle is the strategy of hurrying to finish work at maximum frequency and then entering a deep sleep state, grounded in the idea that the faster the work finishes, the shorter the time leakage current flows. The larger the leakage share in a newer process, the more advantageous in total energy it becomes to turn off entirely rather than drag on at low voltage. Actual measurement studies report that because idle-state power is far smaller than active power, finishing fast at high frequency and transitioning to idle can be effective enough to offset the gains of active-power optimization. In the end, modern systems use both strategies together, and the optimal point depends on the leakage-to-dynamic power ratio, the idle-entry overhead, and whether the work is memory-bound or compute-bound.

Conversely, there are clearly cases where the low-voltage-holding strategy is advantageous. If it is a steady load with work coming in without pause, there is no gap to enter deep sleep in the first place, so lowering voltage to reduce dynamic power is better. Also, in cases like memory-bound sections where lowering frequency causes little performance loss, race-to-idle merely wastes power. On top of this, a deep sleep state costs no small amount of energy and delay to enter and exit, so if the idle section is not long enough, sleeping is actually a loss. Therefore the simple rule "always finish fast and sleep" is wrong, and actual governors look at both the load pattern and idle prediction and dynamically mix the two strategies.

Real systems do not use these strategies exclusively but layer them hierarchically. Hardware takes charge of fine adjustment on a µs scale, the OS governor specifies the range on an ms scale, and the scheduler decides which core to place work on—roles are divided this way. The table below compares the major control methods, and one should read not the numbers but "on what basis it judges and what price it pays."

Method Judging agent Reaction delay Advantage Limit
ondemand/conservative OS (timer) tens of ms simple, general insensitive to abrupt load change
schedutil OS (scheduler-linked) a few ms accurate, EAS-linked depends on governor choice
Speed Shift/HWP, CPPC hardware tens of µs ultra-low latency, high efficiency reduced OS visibility
big.LITTLE+EAS OS + heterogeneous HW a few ms energy-optimal placement depends on model accuracy

4. Application Cases and Comparison

The actual effect of DVFS appears differently depending on the objective function of the application domain. In mobile SoCs, Qualcomm Snapdragon and Apple A/M series combine dozens of OPPs, heterogeneous cores, and hardware governors to momentarily accelerate performance cores for short bursts such as screen touches and scrolling, then immediately drop to efficiency cores and low voltage to save battery. The key metric here is not average power but "all-day battery life relative to perceived responsiveness," and the DVFS transition delay must be as short as tens of µs so the user does not feel slowness.

Concretely, looking at the moment a user presses an app icon, a performance core shoots up to maximum frequency for tens of ms to draw the screen-transition animation without stutter, and once the animation ends and the screen is static, it returns within a few ms to the efficiency core's low-voltage state. This "momentary acceleration then immediate return" pattern is the mobile implementation of race-to-idle, and if the transition is even slightly late, animation frames are pushed back and the user perceives "jank." One reason Apple has vertically integrated OS, scheduler, and power control on its own SoCs is precisely to handle this transition extremely fast and precisely.

In data centers / HPC, the goal is entirely different. Because thousands of nodes must run within rack power limits and cooling capacity, DVFS is used not for an individual node's battery but to comply with total cost of ownership (TCO) and power capping. HPC evaluation studies report that in memory-bound sections, lowering frequency causes little performance degradation so energy can be saved, whereas in compute-bound sections, lowering frequency lengthens execution time and can instead increase total energy. That is, even the same DVFS splits into gain or loss depending on workload characteristics.

Let us see the intuition of this gain/loss with simple numbers. In a memory-bound kernel where the CPU often stalls waiting for data to arrive from memory, lowering core frequency by 33% from 3.0GHz to 2.0GHz may lengthen execution time by only about 10%, because memory latency dominates. At this point dynamic power, with voltage lowering layered on, drops to less than half, so total energy decreases greatly. Conversely, in a compute-bound kernel where the CPU computes without rest, lowering frequency by 33% lengthens execution time nearly proportionally by 50%, so even though instantaneous power drops, the time leakage current flows lengthens and total energy can instead rise. For a data-center operator to "stay within the power cap but minimize performance loss," power-aware scheduling that differentially applies DVFS policy per node and per section in this way is needed.

In embedded / automotive, heat and reliability come to the fore. Because a fanless sealed ECU or industrial controller suffers a sharp drop in lifetime when heat accumulates, thermal throttling—lowering frequency when it approaches a critical temperature in conjunction with a temperature sensor—operates as another face of DVFS. In this case the goal of DVFS is not power saving but "guaranteeing continuous operation within the rated temperature." That said, in systems where real-time behavior matters, such as automotive and aerospace, DVFS becomes a double-edged sword. Because lowering frequency lengthens the worst-case execution time (WCET) and creates a risk of missing deadlines, such systems fix a frequency floor for safety-critical tasks or allow DVFS only in a limited way. That is, the balance between power/thermal efficiency and real-time guarantees must be designed explicitly. The lesson that runs through all three domains is that DVFS is a single technology, yet because what it optimizes differs by design, the evaluation criteria must differ as well.

Comparing DVFS with neighboring techniques makes its position clear. Clock gating stops only the clock of unused blocks to reduce dynamic power, but leaves voltage as-is, so its effect is limited; power gating cuts off a block's power entirely to eliminate even leakage, but its restart delay is large. DVFS is the middle solution between these two that "adjusts voltage and frequency while maintaining performance," and a real chip uses all three techniques together per situation. Undervolting, which lowers the voltage itself to the safe limit, and AVS (Adaptive Voltage Scaling), which reflects the differing characteristics of each chip, can be seen as extensions that push the voltage axis of DVFS more aggressively.

The practical implication to read from this comparison is that the three techniques each take charge of a different time scale and a different power component. Clock gating is used for fine control that stops and wakes blocks on a nanosecond scale, DVFS changes the operating point on a microsecond-to-millisecond scale, and power gating turns a block off wholesale during sections idle for more than milliseconds. Because the larger the restart delay and transition energy, the longer the idle section must be to yield a gain, the designer combines the three techniques hierarchically on the basis of "how much and how often this block rests." This is why DVFS should be understood not as a standalone technology but on the spectrum of power-management techniques.

5. Deep Dive: Latest Trends and a Security Perspective

Although DVFS is a mature technology, it continues to evolve even recently, and the fact that it is simultaneously being pointed to as a new attack surface is especially important from a professional engineer's perspective. This section looks at three currents: the integration of control, application-awareness, and the paradox on the security side.

In particular, in the age of AI accelerators, the center of gravity of DVFS is shifting from a single CPU to the whole chip. As GPUs and NPUs consume enormous power, the cost of large-scale inference and training is in effect determined by compute performance per watt. For this reason, system-level power orchestration that integrally manages the accelerator's own DVFS, the power state of memory (HBM), and the power-budget allocation among multiple accelerators has become a core competitiveness. It has expanded beyond a single core's voltage and frequency into the problem of simultaneously optimizing the operating points of hundreds of compute units within a power cap.

On the technology-evolution side, control is increasingly going in the direction of hardware-scheduler integration. As with Intel Speed Shift and AMD CPPC, hardware autonomously adjusts on a µs scale, and Linux binds scheduling and power decisions into a single loop with schedutil+EAS. In addition, frameworks such as DTPM (Dynamic Thermal Power Management) that allocate the power budget across the entire device tree have been introduced into the Linux kernel, developing into a structure where CPU, GPU, and NPU negotiate over a shared power limit. In AI accelerators and data centers, as "inference performance per watt" becomes the key metric, DVFS is trending toward expansion beyond a single core into system-level power orchestration encompassing accelerators and memory.

Furthermore, machine-learning-based power control is being researched and commercialized. Whereas past rule-based governors relied on simple heuristics such as "raise one step if utilization exceeds a threshold," recently approaches are attempted that learn workload patterns to predict the load of the next section and change the operating point preemptively. If prediction is accurate, performance can be raised only at the needed moment without reaction delay, improving both power and perceived performance. That said, since the computation and memory cost of the learning model itself and the loss upon misprediction must be considered together, it is still an area requiring careful design.

Another current is software / application-aware DVFS. Past governors relied only on the indirect signal of CPU utilization observed by the OS, but recently attempts to link application-level hints—such as frame-rendering deadlines (mobile games, displays), network packet arrival periods, and inference batch boundaries—into power control are increasing. For example, in a section where the screen refreshes at 60Hz, it raises the frequency only enough to draw frames on time and sends the remaining time to low voltage. This means a shift to a more refined objective function—"fast enough to meet the deadline" rather than "always fast because utilization is high"—and shows the direction in which DVFS meshes tightly with the entire system software.

On the security side, DVFS has become a double-edged sword. The very characteristic that voltage and frequency can be adjusted by software becomes a channel attackers exploit. Representatively, Plundervolt (CVE-2019-11157) maliciously manipulated the voltage-adjustment interface of Intel CPUs to induce faults in computations in the SGX secure enclave, succeeding—by software alone—at a fault-injection attack that extracts cryptographic keys. Also, Hertzbleed (2022) exploited the property that, due to DVFS, operating frequency varies with power consumption, demonstrating a side-channel attack that infers the secret value of a cryptographic computation by observing only the difference in computation time remotely. These cases show that fine control for the sake of power efficiency can weaken isolation and confidentiality, and suggest that in security-critical computation sections a design that trades performance for security is needed—such as fixing the frequency or blocking access to the voltage interface. In fact, in response to Plundervolt, manufacturers chose to disable the software voltage-adjustment interface in firmware, a case of giving up some of DVFS's degrees of freedom for security. In short, DVFS sits on a triple trade-off involving not only performance and power but also security, and the designer must explicitly decide which axis to concede, and by how much.

6. Considerations and Implications

  • Application strategy — profile the workload first: DVFS is not a technology that "benefits unconditionally once turned on." Compute-bound work can, if frequency is lowered, lengthen execution time and instead increase total energy, while the gain is large for memory-bound and I/O-wait-heavy work. Therefore, before setting governor/OPP policy, one must measure the characteristics of the target workload (whether it is memory-bound, its burst pattern, latency sensitivity) and choose the policy accordingly.

  • Trade-off — the triangular balance of power, performance, and transition cost: Each time frequency is changed, PLL re-lock and voltage stabilization incur a transition delay of a few µs to tens of µs and a small amount of transition energy. Because overly frequent transitions are instead a loss, the governor's margin and transition period must be coordinated among responsiveness (low latency), efficiency (low power), and stability (suppressing excessive transitions). Since which of race-to-idle and holding low voltage is advantageous depends on the leakage-to-dynamic power ratio, a judgment that even considers the process generation is needed.

  • Outlook — system-level power orchestration: The center of control is moving from the OS to hardware-scheduler integration, and from a single CPU to power-budget negotiation encompassing CPU, GPU, NPU, and memory. Going forward, DVFS will settle beyond adjusting individual components into one axis of a larger picture that allocates the whole chip's power/thermal budget in real time under a framework like DTPM. As performance per watt becomes a competitiveness metric of the AI era, its importance grows further.

  • Alignment with related technologies: DVFS yields its full effect only when designed together not standalone but with clock gating, power gating, thermal throttling, idle-state (C-state) management, and heterogeneous-core scheduling (big.LITTLE, EAS). In particular, since the scheduler (where to run) and the governor (how fast to run), if separated, diverge from each other, it is desirable to design and tune them from an integrated viewpoint, as with schedutil+EAS.

  • Security and reliability considerations: As Plundervolt and Hertzbleed show, the ability to adjust voltage and frequency by software can be a channel for fault-injection and side-channel attacks. In security-sensitive computation sections, apply frequency fixing or control of access to the voltage interface, and in systems where functional safety matters, such as automotive and medical, the frequency floor under worst-case conditions must be designed explicitly so that DVFS does not harm the real-time response-time (WCET) guarantee.

  • Clarifying the target metric: Before establishing a DVFS policy, one must first nail down "what to minimize/constrain." Total energy (electricity bill, carbon), instantaneous power (heat, lifetime), and peak power (rack, power-supply limit) are different objective functions, and a setting that makes one better can worsen another. In the measurement/validation stage too, one must choose a benchmark matched to this metric to avoid the distorted optimization of "power dropped but cost and perceived performance worsened."

In sum, DVFS is a mature technique proven over some twenty years, yet it is still an area of high design difficulty amid new environmental changes such as rising static power, heterogeneous architectures, AI accelerators, and security threats. From a professional engineer's perspective, DVFS should be viewed not as a mere "technology for lowering the clock" but as a system-design problem that coordinates the multi-axis trade-off of power, performance, heat, security, and real-time behavior to match workload characteristics and operating goals. Where to place that balance has no single fixed answer, and correct design begins from first defining the objective function of the application domain.

References

In one line: DVFS is a power-management technique that adjusts voltage and frequency together to match load and pull down the V²·f term; thanks to the voltage-squared effect it saves power overwhelmingly more than simple frequency adjustment, yet the gain/loss between race-to-idle and holding low voltage splits by static power, transition cost, and workload characteristics, and while it underpins performance per watt from mobile to HPC, it is a trade-off-based technology that becomes a security surface as in Plundervolt and Hertzbleed.