Article contents · twelve chapters
Power, latency, and correct work
This guide distinguishes Intel and AMD policies, with an independent Arm comparison. All model values are synthetic. None describes measured N100 behaviour. The eight labs above implement bounded examples; system sleep routing, heterogeneous scheduling and full platform restore sequences remain reference explanations.
1. Start with a workload, not a list of switches
Imagine a small service receiving a request every few milliseconds. The CPU parses the request, a synthetic network device transfers data, and the service returns a result. Between requests, there may be an opportunity to reduce power.
The lesson follows five moments:
- A request arrives and useful work executes.
- Work and unnecessary wakeups stop.
- Eligible components enter lower-power states.
- A new event wakes the required components.
- The next request completes correctly.
The challenge is not merely to make an indicator say “asleep.” The challenge is to establish why a transition was permitted, what actually happened, and whether the next operation still meets its contract.
The first interaction: what is keeping the system awake?
PM-03 compares four equal jobs spread across a 20 ms window with the same work clustered together. Its table shows arrivals, service intervals, contiguous idle gaps and lateness. PM-04 separately shows how endpoint traffic holds a synthetic package active.
Predict which run creates the longer uninterrupted idle interval, then step through its event trace and calculated energy. Both runs complete the same four jobs; the tables also expose any lateness.
Beginner takeaway: Finishing work and staying idle are different achievements.
Professional question: Is the limiting factor workload placement, an interrupt, a latency constraint, an active device, or an unavailable platform state?
2. Power management has several independent layers
The letters in power-state names refer to different objects. They must not be presented as one ladder that every component climbs together.
| Layer | What changes? | Terms a reader will encounter | What it does not prove |
|---|---|---|---|
| Active CPU performance | The operating performance level while instructions execute | P-states, performance requests, frequency, EPP | That the CPU or system is asleep |
| CPU idle | A logical CPU or core stops executing useful instructions | C-states, idle states | That the whole package entered the same depth |
| Package or shared domain | Shared processor resources become eligible for lower power | Package C-states; platform-specific domains | That all devices are powered off |
| PCIe link | Link power behaviour changes | L0, L0s, L1, supported L1 substates | That the endpoint function is in D3 |
| Device function | A device enters a device power state | D0, optional D1/D2, D3hot, D3cold | That the entire system suspended |
| System | The operating system coordinates system-wide sleep | Suspend-to-idle, suspend-to-RAM, hibernation | That each platform implements the same sleep options |
The CPU terminology is grounded in ACPI processor control; the device and system terminology is described separately by Linux's PCI PM and system-sleep documentation.[acpi-processors][pci-pm][sleep-states]
A T-state is a throttling concept, not another name for a P-state or idle state. It is a throttling mechanism, not the normal efficiency control.[acpi-processors]
Three distinctions to keep visible
Requested is not observed. A software request is evidence of intent. It is not proof that hardware entered the deepest permissible state.
Core is not package. On the documented Intel example, package-state resolution depends on core states and platform conditions; a core can be deeper than its package.[intel-package]
Idle is not runtime suspend. A CPU becoming idle is not a command for its device drivers to suspend every device. Runtime PM is a separate device-management mechanism.[device-pm]
Names in the labs. Invented states are called MODEL_IDLE_LIGHT and MODEL_IDLE_DEEP. A real hardware name, such as a particular package C-state, appears only where a selected platform profile has a public reference for it. A numeric state label does not identify identical circuitry across Intel, AMD and Arm.
3. Strategy one: optimize energy per completed job
A power reading is a rate. Energy accounts for that rate over time:
Energy [J] = integral of power [W] over time [s]
For a piecewise-constant teaching model:
Energy = sum(power_in_interval × interval_duration)
Energy per successful job = total measured energy / successful jobs
Choose the measurement boundary before comparing policies. “CPU package,” “whole board,” and “wall outlet” are different experiments. Keep that boundary identical across the comparison.
Worked example: race to idle versus a slower operating point
These are deliberately synthetic whole-system values. Each policy completes the same job within a 100 ms observation window; the remainder is spent at 4 W idle. Transition overhead is omitted in this first example and introduced in Section 5.
| Policy | Active power | Job duration | Idle duration | Total energy |
|---|---|---|---|---|
| Finish quickly | 60 W | 10 ms | 90 ms | 0.960 J |
| Run more slowly, case A | 20 W | 25 ms | 75 ms | 0.800 J |
| Run more slowly, case B | 20 W | 40 ms | 60 ms | 1.040 J |
For the fast policy:
60 × 0.010 + 4 × 0.090 = 0.960 J
Case A saves energy. Case B does not. With a 15 ms completion deadline, neither slower case is acceptable regardless of its energy result.
The conclusion is conditional: finishing sooner can earn valuable idle time, but a higher active power level does not automatically minimize energy. Conversely, choosing the lowest frequency does not automatically minimize energy either.
Explore: “Which policy wins?”
In PM-01, compare the three declared profiles across the same 100 ms boundary and change the job deadline. The table reports completion time, total energy and deadline status. A profile that misses the deadline is not an acceptable winner.
PM-01 excludes transition overhead. PM-02 includes an explicit 600 μJ deep-state overhead exactly once; its values are small enough to verify by hand.
Neither “Turbo always saves power” nor “Lower clocks are always greener” follows from these examples. Compare the supplied workload, deadline and measurement boundary.
4. Strategy two: choose an appropriate active-performance policy
Linux separates CPU performance scaling from idle management. CPUFreq uses policy objects, scaling drivers, and, where applicable, governors. A policy may cover multiple CPUs sharing a control interface. A reported frequency is not necessarily a direct measurement of the frequency actually delivered throughout an interval.[cpufreq]
Intel path: HWP and energy-performance preference
On supported Intel systems, hardware-managed P-states (HWP) let software express performance bounds and preferences while hardware chooses operating performance. intel_pstate has active and passive modes, and the meaning of powersave depends on the driver and mode. In particular, the active-mode powersave policy is not simply the generic CPUFreq instruction to hold the minimum frequency. EPP is a preference, not a guaranteed frequency or wattage.[intel-pstate]
Reference only: requested bounds, EPP, delivered performance and completed work are distinct observations. The current synthetic profiles do not execute HWP or expose an EPP control.
AMD path: CPPC and amd-pstate
On supported AMD systems, amd-pstate uses Collaborative Processor Performance Control (CPPC). Its performance scale is not a universal GHz scale. The documented modes are active/autonomous, passive/non-autonomous, and guided autonomous. Active mode uses minimum, maximum, and energy-performance preference inputs; passive mode involves an OS-selected desired performance level; guided mode combines OS constraints with autonomous selection. The available mode and behaviour depend on platform support and configuration.[amd-pstate]
Reference only: the meaning of a control depends on the selected amd-pstate mode. The current labs do not execute CPPC or switch the host driver mode.
How to explain the silicon underneath
These mechanisms explain different responsibilities; they are not a register-programming recipe:
| Mechanism | Teaching explanation | Necessary qualification |
|---|---|---|
| Voltage/frequency adjustment | Change the operating point used for active work | Only supported operating points and controls are in scope |
| Clock gating | Stop unnecessary switching in eligible logic | A stopped clock does not mean a supply was removed |
| Power gating | Remove power from an eligible region | State retention or restoration becomes part of the design |
| Retention | Preserve selected state across a lower-power interval | Retained state is a platform property, not a global assumption |
The public Intel material illustrates multiple core, graphics, memory, and platform power mechanisms; it is not a single CPU-frequency switch. These mechanisms are a conceptual explanation, not a claim about the internal implementation of every x86 processor.[intel-pm]
Reference extension: compare a stream of requests
A future workload experiment could replay a fixed request stream under responsiveness-first, balanced and energy-preferred policies, preserving arrivals and checking response-time distributions. This is not implemented here. PM-01 instead compares one identical job under three declared profiles over a fixed 100 ms window.
A result for one workload does not establish the best policy for every workload.
5. Strategy three: choose idle depth using time and latency
Linux CPUIdle describes states using target residency and exit latency. A governor selects an eligible state; a driver requests it. Actual hardware residency can differ from software-accounted idle time, so hardware residency counters, where available, provide a different level of evidence.[cpuidle]
Target residency answers: “Is the expected gap long enough for this state to be worthwhile?”
Exit latency answers: “Can execution resume quickly enough when work returns?”
A transparent break-even model
For a simplified comparison between a light and deep state:
T_break_even = additional_transition_energy / (P_light - P_deep)
Assume P_light > P_deep. Define additional transition energy consistently relative to the full-gap baseline; do not count the same entry/exit energy twice.
Use these invented values:
Light idle power: 2.0 W
Deep idle power: 0.5 W
Additional transition energy: 0.6 mJ
Break-even time: 0.0006 / 1.5 = 400 microseconds
Deep-state exit latency: 100 microseconds
A predicted 2 ms gap can justify the deeper state in this model. A 200 microsecond gap cannot. A 50 microsecond wake-latency budget rejects the deep state even during the longer gap.
This equation is an explanatory energy model, not a replacement for the driver's state data or a claim that every Linux governor calculates residency this way.
Latency is a budget, not just a state property
PM QoS lets software express power-management constraints, including latency requirements. Different consumers can impose constraints that affect which idle choices are eligible.[pm-qos]
A service's response time also includes queueing and useful execution. Do not equate a 100 microsecond CPU exit-latency limit with a 100 microsecond end-to-end request guarantee.
Explore: “Why was deep idle rejected?”
The idle-state lab takes four inputs: predicted gap, wake budget, supported states and a platform eligibility condition. It shows the rejection reason beside each candidate.
MODEL_IDLE_DEEP: rejected — exit latency exceeds the configured budget
MODEL_IDLE_LIGHT: selected — supported, eligible, and within both limits
The lab can inject an unexpectedly early wakeup and shows the difference between prediction and outcome. A bad prediction costs energy; it is not by itself a functional failure.
6. Strategy four: create useful idle windows
A periodic scheduler tick can disturb an otherwise idle CPU. Linux's NO_HZ_IDLE mechanism can suppress idle scheduling ticks; it does not eliminate every interrupt, timer, or source of background activity. Full adaptive tick handling is a separate, more specialized configuration, not a required first step for an energy-saving demonstration.[no-hz]
Start the investigation with avoidable work: a needless polling loop, redundant status queries, excessive timer frequency, or repeated tiny tasks that can tolerate batching.
Experiment: equal work, different timing
PM-03 schedules four 500 μs jobs across a 20 ms window. Compare the arrival-time schedule with the clustered schedule: both perform 2,000 μs of service, but the contiguous idle gaps differ.
Reduce the batching allowance and inspect the reported lateness. This fixture deliberately retains the chosen schedule to reveal its cost; it does not automatically reschedule a late task.
Positive strategy: consolidate deferrable work when the workload permits it.
Trade-off: waiting for a batch can add response delay. PM-03 reports that cost alongside the idle gaps.
Placement and topology
With two cores sharing a domain, packing compatible background work may leave another core idle, but contention can extend execution. PM-ARM-01 demonstrates the shared-domain eligibility rule. A scheduling and contention simulator remains outside this release.
On the selected Intel reference platform, package state depends on conditions beyond the local core request.[intel-package] Use this as a platform-specific example of why a low CPU-utilization number is insufficient evidence.
Reference only: CPU affinity, CPU offlining and hardware power gating are separate mechanisms. None is controlled by this lab.
7. Strategy five: include PCIe links and devices
This section connects power management to the existing PCIe/IOMMU story without turning every power transition into an IOMMU reset.
7.1 Link power is not device power
PCIe Active State Power Management (ASPM) concerns link power. Supported states and substates must be checked for the relevant ports and platform. Intel's referenced datasheet provides a concrete example of dependencies between PCIe link states and package C-states; that table must not be generalized to all processors, or assumed to describe an N100 system.[intel-pcie]
Device D-states describe a different object. For PCI PM, D3hot remains software-accessible through configuration space, whereas D3cold involves removal of the main supply and requires restoration of power. Optional auxiliary wake circuitry is a separate consideration.[pci-pm]
Explore: “The cores are idle, but the package is not”
Use a declared synthetic platform profile containing a root port and one endpoint. Give it an explicit dependency rule: the deepest model package state requires an eligible link state.
In PM-04, change endpoint traffic, the root-plus-endpoint capability, policy and core eligibility separately. The evidence table distinguishes the requested policy from the observed synthetic link and package states.
Do not simulate link sleep by pretending that an application manually powers down the device for each idle packet gap.
7.2 Runtime PM is a coordinated device lifecycle
Linux runtime PM tracks device use and coordinates suspend and resume through the driver and surrounding infrastructure. Usage accounting, pending resume activity, autosuspend policy, and dependencies matter; setting a permissive policy does not itself prove a device is suspended.[runtime-pm]
For a teaching device, define states that are explicitly model states:
| Current state | Condition | Next state |
|---|---|---|
| ACTIVE | Submission closes | QUIESCING |
| QUIESCING | Work accounted for, acknowledgement and wake route ready | SUSPENDED |
| QUIESCING | Wake arrives before entry | ACTIVE (safe abort) |
| SUSPENDED | Wake latched | RESUMING |
| RESUMING | Context and synchronization verified | ACTIVE |
| QUIESCING / RESUMING | Bounded prerequisite timeout | RECOVERY_REQUIRED |
An autosuspend delay trades repeated transition costs against remaining active between bursts. The lifecycle labs test correctness of one transition; they do not yet simulate an autosuspend-delay policy sweep.
7.3 Other components deserve their own scope
A memory controller and DRAM have power-management mechanisms distinct from core idle. Intel's public memory-controller documentation provides one platform example.[intel-memory] Storage-controller power policies, graphics, displays, USB, and network PHYs should likewise be separate follow-on modules, not unexplained subcontrols of “CPU power saving.”
These subsystems are reference scope here. No protocol-specific control or capability is claimed for an attached peripheral.
8. Strategy six: preserve correctness through device sleep and wake
A power saving is not useful if it corrupts a buffer, loses a completion, or returns a broken device to service.
First, choose which transition is being tested
| Transition under test | What the lesson should establish |
|---|---|
| Ordinary CPU idle while a device remains active | The selected platform can continue or service device traffic through its normal supported paths; the lesson must not require a global device shutdown |
| Runtime suspend of the synthetic DMA device | New submissions are controlled, device activity is safely quiesced, and the device's power prerequisites are satisfied |
| System sleep | The operating system, drivers, buses, firmware, and wake sources follow the selected system-sleep contract |
| Loss of an IOMMU or device context in a declared model profile | Required state is restored before dependent traffic is permitted |
Important boundary: “A CPU entered an idle state” must never automatically become “the IOMMU lost its configuration.” Context retention is a property of the affected component and transition, not a consequence that can be inferred from the word “sleep.”
Linux's device-PM documentation describes quiescing I/O, saving or reinitializing required state, and ordered suspend/resume. Main device suspend/resume traversal generally follows child-before-parent and parent-before-child ordering, with distinct preparation and completion phases.[device-pm]
A conservative synthetic DMA-device story
PM-05 and PM-06 implement the following bounded simulator contract. It is not a universal driver recipe or hardware sequencing specification.
| Step | Visible event | Evidence the model must provide |
|---|---|---|
| 1 | Close the submission gate | No new ordinary transfer is accepted after the boundary |
| 2 | Finish or safely cancel accepted work | Every accepted transfer reaches a defined terminal outcome |
| 3 | Establish device quiescence | A model acknowledgement, not merely an empty UI queue |
| 4 | Prepare wake and context handling | Declared wake route is ready; retained/lost state is explicit |
| 5 | Enter device low power | All prerequisites are satisfied; the transition is recorded |
| 6 | Receive a wake event | The event is latched and cannot disappear in an entry race |
| 7 | Restore dependencies and required context | The affected device and protection path are ready before new traffic |
| 8 | Reopen the submission gate | A valid transfer succeeds and an unauthorized transfer remains blocked |
Use separate evidence for a driver deciding to suspend, a device acknowledging quiescence, and a model entering its low-power state. These are different events.
DMA ownership is not the same as address translation
The Linux DMA API distinguishes coherent and streaming mappings, mapping lifetime, and synchronization requirements. Coherent allocations do not remove all ordering requirements. A teaching model should therefore keep buffer ownership, data visibility, and translation/protection validity separate.[dma-api]
Do not automatically unmap every buffer when a device sleeps. Specify whether a scenario retains mappings, changes them, or loses device context. When a scenario changes translations or loses relevant state, use the separately reviewed IOMMU/SMMU backend's ordering and completion rules.
This fixture represents the protection path with a readiness flag and a context generation. It invents no AMD or Arm invalidation opcodes to animate a resume sequence.
The negative test that makes this lesson valuable
Inject “device resumed, protection context not restored.” The corrected controller must keep ordinary DMA submissions blocked, record the missing prerequisite, and move to a bounded recovery path if restoration times out.
Then deliberately run the broken-controller variant. A forbidden transfer reaching protected memory should produce a visible failed invariant, not a green “resume complete” badge.
Validation beyond this fixture: test both an allowed transfer and a deliberately denied transfer after resume. A successful allowed transfer establishes functionality, not isolation. PM-05/06 exercise controller guards and a synthetic buffer byte; they do not execute the full IOMMU walker for a post-resume denial. Use the DMA journey for actual modelled permission checks, and do not treat the two independent lessons as an end-to-end hardware test.
9. Strategy seven: treat system sleep as its own lifecycle
Linux exposes distinct sleep mechanisms, including suspend-to-idle, suspend-to-RAM where supported, and hibernation. Supported choices vary by platform and configuration. The strings in /sys/power/state and /sys/power/mem_sleep report available mechanisms and the selected memory-sleep variant.[sleep-states]
Do not present a vendor/platform low-power residency label, an operating-system suspend method, and a CPU C-state as synonyms. Selecting suspend-to-idle is not, by itself, evidence that a particular deep platform residency was achieved.
Explore: “Who can wake the system?”
A real system transition needs a declared wake route through the device’s parent resources to the receiving component. The device lifecycle lab assumes this route is available and lets you inject wake before, during or after entry. Full system-sleep routing remains a reference topic.
A correct model handles all three without losing the event. It may abort entry or wake immediately; that is not automatically a failure.
The fixture shows why a suspend request was rejected, and a timed-out resume is not reported as a successful transition merely because a callback was invoked.
Scope limit: the executable lifecycle is a synthetic device transition. Full system sleep remains reference-only. No browser control changes or suspends the hosting machine.
10. Strategy eight: use power limits without confusing them with energy results
Intel's public package-power-control documentation distinguishes controls including PL1, PL2, and an averaging time parameter. Their interpretation belongs to the documented processor and firmware configuration; they are not a promise that wall power remains below a displayed number at every instant.[intel-power-limits]
AMD's EPYC 9004/8004 power-management material describes a separate platform-specific set of controls, including configurable TDP and boost behaviour. Do not rename those controls to Intel register terminology or assume the same limits exist on all AMD systems.[amd-power]
Compare: find a useful operating envelope
For a fixed synthetic workload, the lab sweeps a model power cap and records completion time, energy per job and deadline misses, so the result is a trade-off curve rather than a single “best” percentage.
Compare only configurations that meet the correctness and performance requirements. Report whether the chosen point is lowest energy, lowest peak power, or fastest completion; these are different objectives.
A thermal limit is a separate cause of reduced performance, so a delivered-performance shortfall is not always the EPP setting.
Do not include in a beginner module: undervolting recipes, disabled thermal protections, forced unsupported ASPM, or broad register-write commands. Platform tuning belongs in a separately scoped and reversible hardware procedure.
11. Measure intent, behaviour, and outcome separately
A useful hardware evidence record separates three columns:
| Intent | Behaviour | Outcome |
|---|---|---|
| Requested performance range | Observed performance over the interval | Completed work and response time |
| Requested idle state | Available hardware residency evidence | Energy used during the observation window |
| Permitted runtime PM | Runtime state and transition trace | Device remains usable after wake |
| Resume requested | Context and dependency restoration | Positive and negative I/O tests pass |
Linux power tracepoints can expose events such as CPU idle, CPU frequency, and suspend activity. An event identifies what that tracepoint reports; it should not be relabelled as an electrical measurement.[power-trace]
Where exposed, the Linux powercap interface includes energy counters and range information. Derive interval-average power from an energy delta and elapsed time. Keep zone names and measurement boundaries visible, and do not add overlapping package and subzone energy as if they were independent totals.[powercap]
Evidence checklist for a real experiment
Record the machine model, CPU identification, firmware and microcode versions, kernel version, active drivers, relevant policy settings, workload revision, workload results, timing method, ambient/test conditions, and measurement boundary. Record unavailable counters as unavailable—not zero.
Use a warm-up period, repeated runs, and an unchanged workload. Alternate baseline and candidate runs when drift could matter. Report sample count and variability; select acceptance thresholds before inspecting the results.
For bursty services, a latency distribution says more than the mean, and the first request after idle is worth comparing separately from steady traffic. If measuring an energy counter, detect counter reset and wrap; a modulo calculation is only unique when a justified bound establishes that total increment is strictly less than the counter range, or an exact wrap count is independently known. “At most one wrap” is insufficient: 100→200 with range 1000 can mean increments 100 or 1100. Equal readings can mean zero or a full-range increment. The exercise starts with no such evidence, keeps ambiguity explicit and exports the selected assumptions.
Optional read-only Linux inspection
These commands only inspect the named operating-system interfaces. Their presence, contents, and permissions vary. They do not select a governor, enable ASPM, change a device state, or suspend the host.[cpufreq][cpuidle][sleep-states]
# Bash: report missing interfaces without trying to create or enable them.
show_file() {
if [ -r "$1" ]; then
printf '\n%s\n' "$1"
cat -- "$1"
else
printf '\n%s: unavailable or not readable\n' "$1"
fi
}
uname -r
show_file /sys/devices/system/cpu/cpuidle/current_driver
show_file /sys/devices/system/cpu/cpuidle/current_governor_ro
show_file /sys/power/state
show_file /sys/power/mem_sleep
for policy in /sys/devices/system/cpu/cpufreq/policy*; do
[ -d "$policy" ] || continue
show_file "$policy/scaling_driver"
show_file "$policy/scaling_governor"
show_file "$policy/energy_performance_preference"
done
Run host observation separately from the browser simulator. A container or virtual machine may not expose the physical host's complete controls or counters; missing visibility is not proof that the physical feature does not exist.
12. Bonus: the same engineering questions on Arm
This bonus focuses on Arm A-profile systems, not a universal recipe for every Arm microcontroller, phone, or server. Reuse the questions—energy, latency, dependencies, and correctness—but keep the interfaces architecture-specific.
12.1 Start with a domain tree
Instead of copying x86 package C-state numbers, this section uses a synthetic hierarchy:
| Domain | Children / dependency |
|---|---|
| System | Shared CPU domain and device domain |
| Shared CPU domain | CPU0 and CPU1 |
| Device domain | DMA device and protection dependency |
Trusted Firmware-A describes a platform-supplied hierarchy of CPU and non-CPU power domains. Its PSCI coordination design distinguishes platform-coordinated and OS-initiated approaches; optional modes must not be presumed available merely because the architecture defines them.[psci-tree][psci-coordination]
Interaction: CPU 0 requests a low-power state while CPU 1 is still active. The shared model domain remains available. Once both children are eligible, the model may consider a deeper parent state. The evidence table identifies the active child holding the parent awake.
12.2 PSCI: CPU and system power-state coordination
The Power State Coordination Interface provides calls such as CPU_SUSPEND, CPU_ON, and CPU_OFF, with feature/version discovery and platform-specific implementation support. Trusted Firmware-A's implementation documentation explicitly notes dependencies on platform power-management hooks.[psci-firmware]
Linux's PSCI device-tree binding describes firmware-call conduits such as SMC and HVC, plus CPU and domain idle-state descriptions. A conduit is a calling path; it is not an energy policy.[psci-binding]
For a powerdown-style suspend demonstration, model entry and eventual resumed execution. Do not draw CPU_SUSPEND as an ordinary asynchronous acknowledgement that returns to the caller while that CPU remains powered off.
12.3 WFI is not a complete system power policy
A wait instruction is not proof that every clock, cache, interconnect, and device has turned off. Arm core documentation distinguishes idle/wait conditions from specific retention and power modes; the combination depends on the implementation.[arm-core-modes]
Use the plain-language question “What state can this platform enter now?” rather than “Did the processor execute the magic sleep instruction?”
12.4 SCMI: management requests to platform firmware
The System Control and Management Interface is a set of interfaces for power, performance, and system management. It serves a different role from PSCI; do not call it an Arm synonym for Intel HWP.[arm-scmi]
ST's public SCMI integration documentation gives a concrete example of exposed clock, reset, voltage, and performance protocols. That example illustrates discoverable services, not a guarantee that every Arm SoC exposes the same protocol set or transport.[scmi-integration]
PM-ARM-01 uses semantic domain requests to distinguish accepted, constrained and unsupported outcomes. A full SCMI performance-level experiment remains reference scope. Its model labels are not SCMI wire-format status codes.
12.5 Placement: heterogeneous does not mean “always use the small core”
Linux Energy Aware Scheduling uses an energy model to help place work on supported heterogeneous CPU topologies. It is not a generic guarantee that every Arm platform has heterogeneous cores or uses EAS.[eas]
Compare CPU types using explicit execution-time, energy and migration-cost measurements. Sometimes a lower-power CPU meets the deadline efficiently; sometimes it cannot. Heterogeneous task placement is explained here but is not an executable scheduling lab.
12.6 Keep the SMMU lesson separate from the power controller
Reuse the generic validation requirement from Section 8: the protection path must be ready before a resumed device submits dependent traffic. But retain a separate Arm SMMU backend for architecture-specific state and synchronization. Do not copy AMD queue formats, command names, or context-restoration assumptions into the Arm view.
The shipped power lessons use a declared protection-path readiness abstraction. Full SMMUv3 restoration is future work and requires its own public architectural references and tests.
A comparison card—not an equivalence table
| Question | Intel-oriented example | AMD-oriented example | Arm bonus example |
|---|---|---|---|
| How is active performance influenced? | HWP and intel_pstate on supported systems |
CPPC and amd-pstate on supported systems |
Platform CPUFreq integration, potentially firmware-mediated |
| How are shared idle resources coordinated? | Documented core/package and platform dependencies | The selected AMD platform's documented dependencies | PSCI and the selected power-domain topology |
| What evidence is sufficient? | Requested and observed state remain separate | Same evidentiary separation | Same evidentiary separation |
| What must not be assumed? | One datasheet applies to every Intel SKU | Intel controls describe AMD behaviour | Every Arm system has the same firmware, cores, or power tree |
The implementation examples above are supported by their respective driver and firmware references. The common evidence rules are the design requirements of this educational module, not claims of interchangeable hardware.[intel-pstate][amd-pstate][psci-firmware]
References and source boundaries
The references below were checked, with Linux CPU idle, runtime/device/PCI power, Intel/AMD pstate and Trusted Firmware-A coordination documentation, on 27 September 2026. Live documentation can evolve; synthetic policy decisions are defined in the versioned local model.
Reference review date: 27 September 2026. Linux and Trusted Firmware documentation linked through moving documentation paths can change; pin a release or source commit when implementing a real hardware profile. The Intel examples below intentionally identify an older, public, platform-specific datasheet revision. They are not claims about the newest Intel implementation. Implementation proposals, synthetic arithmetic, test IDs, and simulator labels are original material in this guide.
The source hierarchy is: architecture/firmware standards for defined interfaces, vendor documentation for a named platform, operating-system documentation for software behaviour, and explicit model rules for the teaching simulation. A working model is not standards certification.
The suspend fixture has an explicit ENTERING/commit boundary. A before-entry wake aborts; a during-entry wake is accepted before commit and handled by immediate resume; an after-entry wake is accepted after commit. This bounded model shows causal order, not silicon timing.
- acpi-processors: UEFI Forum, ACPI Specification 6.6, Chapter 8: Processor Configuration and Control. CPU power/performance terminology and CPPC context. Public specification.
- cpufreq: Linux kernel documentation, CPU Performance Scaling. CPUFreq drivers, policies, governors, and the interpretation of frequency attributes. Documentation.
- intel-pstate: Linux kernel documentation, intel_pstate CPU Performance Scaling Driver. Active/passive modes, HWP, and energy-performance hints. Documentation.
- amd-pstate: Linux kernel documentation, amd-pstate CPU Performance Scaling Driver. CPPC, operation modes, and EPP behaviour. Documentation.
- cpuidle: Linux kernel documentation, CPU Idle Time Management. Target residency, exit latency, state selection, and the distinction between software accounting and hardware residency. Documentation.
- pm-qos: Linux kernel documentation, PM Quality Of Service Interface. Latency and other power-management constraints. Documentation.
- no-hz: Linux kernel documentation, NO_HZ: Reducing Scheduling-Clock Ticks. Idle tick suppression and adaptive-tick scope. Documentation.
- intel-pm: Intel, 12th Generation Intel Core Processors Datasheet, Volume 1 of 2, document 655258, revision 005, Power Management. Platform-specific overview and linked subsystem sections. Vendor documentation.
- intel-package: Intel, same named datasheet/revision, Package C-States. Core/package coordination on this reference platform only. Vendor documentation.
- intel-pcie: Intel, same named datasheet/revision, PCI Express Power Management. Link power capabilities and named platform package-state dependencies. Vendor documentation.
- intel-memory: Intel, same named datasheet/revision, Integrated Memory Controller (IMC) Power Management. Example of a separate power-managed subsystem. Vendor documentation.
- intel-power-limits: Intel, same named datasheet/revision, Package Power Control. Platform-specific power-limit controls and associated interpretation. Vendor documentation.
- amd-power: AMD, AMD EPYC 9004 and 8004 Series CPU Power Management, 23 September 2024. Illustrative AMD platform controls; not a universal Ryzen/EPYC tuning recipe. Vendor article.
- device-pm: Linux kernel documentation, Device Power Management Basics. Runtime/system PM distinction, I/O quiescence, and suspend/resume phases. Documentation.
- runtime-pm: Linux kernel documentation, Runtime Power Management Framework for I/O Devices. Device use accounting, callbacks, and autosuspend. Documentation.
- pci-pm: Linux kernel documentation, PCI Power Management. Basic PCI device-state concepts and wake support. Some implementation commentary in this long-standing page is historical; this page uses it for the identified state definitions, not as a current feature-support matrix. Documentation.
- dma-api: Linux kernel documentation, Dynamic DMA Mapping Guide. Mapping lifetime, coherent/streaming distinctions, synchronization, and ordering. Documentation.
- sleep-states: Linux kernel documentation, System Sleep States. Distinct sleep mechanisms and their user-space interfaces. Documentation.
- power-trace: Linux kernel documentation, Subsystem Trace Points: power. Power-related event observability. Documentation.
- powercap: Linux kernel documentation, Power Capping Framework. Energy counters, zones, counter ranges, and power constraints. Documentation.
- psci-tree: Trusted Firmware-A documentation, PSCI Power Domain Tree Structure. Platform topology and parent/child domain representation. Implementation design.
- psci-coordination: Trusted Firmware-A documentation, PSCI OS-initiated mode. Conceptual comparison of platform-coordinated and OS-initiated coordination. This is a design discussion, not an assertion of support in any particular deployed firmware. Design discussion.
- psci-firmware: Trusted Firmware-A documentation, Firmware Design — Power State Coordination Interface. API implementation and platform-hook dependencies. Check the deployed firmware's reported capabilities rather than assuming that documentation support tables describe every build. Implementation documentation.
- psci-binding: Linux kernel source, Documentation/devicetree/bindings/arm/psci.yaml. PSCI calling conduits and topology/idle-state descriptions. Pin the source commit when implementing a profile. Primary source.
- arm-core-modes: Arm Developer, Core power modes, document 107734, issue 0002. A concrete core implementation's mode distinctions, not a universal definition for all Arm cores. Core documentation.
- arm-scmi: Arm Developer, System Control and Management Interface. Scope of SCMI power, performance, and system-management interfaces. Arm overview.
- scmi-integration: STMicroelectronics, SCMI device tree configuration. A public platform integration example of exposed SCMI services and transports. Vendor integration documentation.
- eas: Linux kernel documentation, Energy Aware Scheduling. Energy-model-based placement on supported heterogeneous topologies and its scope. Documentation.