Advanced Configuration and Power Interface Specification

Processor Configuration and Control
runtime, OSPM requests desired performance on this abstract scale and the platform entity is
responsible for translating the OSPM performance requests into actual hardware performance states.
The platform may also support the ability to autonomously select a performance level appropriate to
the current workload. In this case, OSPM conveys information to the platform that guides the
platform's performance level selection.
Prior processor performance controls (P-states and T-states) have described their effect on processor
performance in terms of processor frequency. While processor frequency is a rough approximation
of the speed at which the processor completes work, workload performance isn’t guaranteed to scale
with frequency. Therefore, rather than prescribe a specific metric for processor performance,
Collaborative Processor Performance Control leaves the definition of the exact performance metric
to the platform. The platform may choose to use a single metric such as processor frequency, or it
may choose to blend multiple hardware metrics to create a synthetic measure of performance. In this
way the platform is free to deliver the OSPM requested performance level without necessarily
delivering a specific processor frequency. OSPM must make no assumption about the exact meaning
of the performance values presented by the platform, or how they may correlate to specific hardware
metrics like processor frequency.
Platforms must use the same performance scale for all processors in the system. On platforms with
heterogeneous processors, the performance characteristics of all processors may not be identical. In
this case, the platform must synthesize a performance scale that adjusts for differences in processors,
such that any two processors running the same workload at the same performance level will
complete in approximately the same time. The platform should expose different capabilities for
different classes of processors, so as to accurately reflect the performance characteristics of each
processor.
The control mechanisms are abstracted by the _CPC object method, which describes how to control
and monitor processor performance in a generic manner. The register methods may be implemented
in the Platform Communications Channel (PCC) interface (see Section 14). This provides sufficient
flexibility that the entity OSPM communicates with may be the processor itself, the platform chipset,
or a separate entity (e.g., a BMC).
8.4.7.1 _CPC (Continuous Performance Control)
This optional object declares an interface that allows OSPM to transition the processor into a
performance state based on a continuous range of allowable values. OSPM writes the desired
performance value to the Desired Performance Register, and the platform maps the desired
performance to an internal performance state.. If supported by the platform, OSPM may
alternatively enable autonomous performance level selection while specifying minimum and
maximum performance requirements.
Optional _CPC package fields that are not supported by the platform should be encoded as follows:
• Integer fields: Integer 0
• Register fields: the following NULL register descriptor should be used:
ResourceTemplate() {Register {(SystemMemory, 0, 0, 0, 0)}}
Arguments:
None
Version 6.0 477