요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
==============================
Intel Uncore Frequency Scaling
==============================
:Copyright: |copy| 2022-2023 Intel Corporation
:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Introduction
------------
The uncore can consume significant amount of power in Intel's Xeon servers based
on the workload characteristics. To optimize the total power and improve overall
performance, SoCs have internal algorithms for scaling uncore frequency. These
algorithms monitor workload usage of uncore and set a desirable frequency.
It is possible that users have different expectations of uncore performance and
want to have control over it. The objective is similar to allowing users to set
the scaling min/max frequencies via cpufreq sysfs to improve CPU performance.
Users may have some latency sensitive workloads where they do not want any
change to uncore frequency. Also, users may have workloads which require
different core and uncore performance at distinct phases and they may want to
use both cpufreq and the uncore scaling interface to distribute power and
improve overall performance.
Sysfs Interface
---------------
To control uncore frequency, a sysfs interface is provided in the directory:
`/sys/devices/system/cpu/intel_uncore_frequency/`.
There is one directory for each package and die combination as the scope of
uncore scaling control is per die in multiple die/package SoCs or per
package for single die per package SoCs. The name represents the
scope of control. For example: 'package_00_die_00' is for package id 0 and
die 0.
Each package_*_die_* contains the following attributes:
``initial_max_freq_khz``
Out of reset, this attribute represent the maximum possible frequency.
This is a read-only attribute. If users adjust max_freq_khz,
they can always go back to maximum using the value from this attribute.
``initial_min_freq_khz``
Out of reset, this attribute represent the minimum possible frequency.
This is a read-only attribute. If users adjust min_freq_khz,
they can always go back to minimum using the value from this attribute.
``max_freq_khz``
This attribute is used to set the maximum uncore frequency.
``min_freq_khz``
This attribute is used to set the minimum uncore frequency.
``current_freq_khz``
This attribute is used to get the current uncore frequency.
SoCs with TPMI (Topology Aware Register and PM Capsule Interface)
-----------------------------------------------------------------
An SoC can contain multiple power domains with individual or collection
of mesh partitions. This partition is called fabric cluster.
Certain type of meshes will need to run at the same frequency, they will
be placed in the same fabric cluster. Benefit of fabric cluster is that it
offers a scalable mechanism to deal with partitioned fabrics in a SoC.
The current sysfs interface supports controls at package and die level.
This interface is not enough to support more granular control at
fabric cluster level.
SoCs with the support of TPMI (Topology Aware Register and PM Capsule
Interface), can have multiple power domains. Each power domain can
contain one or more fabric clusters.
To represent controls at fabric cluster level in addition to the
controls at package and die level (like systems without TPMI
support), sysfs is enhanced. This granular interface is presented in the
sysfs with directories names prefixed with "uncore". For example:
uncore00, uncore01 etc.
The scope of control is specified by attributes "package_id", "domain_id"
and "fabric_cluster_id" in the directory.
Attributes in each directory:
``domain_id``
This attribute is used to get the power domain id of this instance.
``die_id``
This attribute is used to get the Linux die id of this instance.
This attribute is only present for domains with core agents and
when the CPUID leaf 0x1f presents die ID.
``fabric_cluster_id``
This attribute is used to get the fabric cluster id of this instance.
``package_id``
This attribute is used to get the package id of this instance.
``agent_types``
This attribute displays all the hardware agents present within the
domain. Each agent has the capability to control one or more hardware
subsystems, which include: core, cache, memory, and I/O.
The other attributes are same as presented at package_*_die_* level.
In most of current use cases, the "max_freq_khz" and "min_freq_khz"
is updated at "package_*_die_*" level. This model will be still supported
with the following approach:
When user uses controls at "package_*_die_*" level, then every fabric
cluster is affected in that package and die. For example: user changes
"max_freq_khz" in the package_00_die_00, then "max_freq_khz" for uncore*
directory with the same package id will be updated. In this case user can
still update "max_freq_khz" at each uncore* level, which is more restrictive.
Similarly, user can update "min_freq_khz" at "package_*_die_*" level
to apply at each uncore* level.
Support for "current_freq_khz" is available only at each fabric cluster
level (i.e., in uncore* directory).
Efficiency vs. Latency Tradeoff
-------------------------------
The Efficiency Latency Control (ELC) feature improves performance
per watt. With this feature hardware power management algorithms
optimize trade-off between latency and power consumption. For some
latency sensitive workloads further tuning can be done by SW to
get desired performance.
The hardware monitors the average CPU utilization across all cores
in a power domain at regular intervals and decides an uncore frequency.
While this may result in the best performance per watt, workload may be
expecting higher performance at the expense of power. Consider an
application that intermittently wakes up to perform memory reads on an
otherwise idle system. In such cases, if hardware lowers uncore
frequency, then there may be delay in ramp up of frequency to meet
target performance.
The ELC control defines some parameters which can be changed from SW.
If the average CPU utilization is below a user-defined threshold
(elc_low_threshold_percent attribute below), the user-defined uncore
floor frequency will be used (elc_floor_freq_khz attribute below)
instead of hardware calculated minimum.
Similarly in high load scenario where the CPU utilization goes above
the high threshold value (elc_high_threshold_percent attribute below)
instead of jumping to maximum uncore frequency, frequency is increased
in 100MHz steps. This avoids consuming unnecessarily high power
immediately with CPU utilization spikes.
Attributes for efficiency latency control:
``elc_floor_freq_khz``
This attribute is used to get/set the efficiency latency floor frequency.
If this variable is lower than the 'min_freq_khz', it is ignored by
the firmware.
``elc_low_threshold_percent``
This attribute is used to get/set the efficiency latency control low
threshold. This attribute is in percentages of CPU utilization.
``elc_high_threshold_percent``
This attribute is used to get/set the efficiency latency control high
threshold. This attribute is in percentages of CPU utilization.
``elc_high_threshold_enable``
This attribute is used to enable/disable the efficiency latency control
high threshold. Write '1' to enable, '0' to disable.
Example system configuration below, which does following:
* when CPU utilization is less than 10%: sets uncore frequency to 800MHz
* when CPU utilization is higher than 95%: increases uncore frequency in
100MHz steps, until power limit is reached
elc_floor_freq_khz:800000
elc_high_threshold_percent:95
elc_high_threshold_enable:1
elc_low_threshold_percent:10
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
소개
1-28이 문서는 `SPDX-License-Identifier: GPL-2.0`을 따르며, 저작권은 2022-2023 Intel Corporation에 있습니다. 작성자는 Srinivas Pandruvada `<srinivas.pandruvada@linux.intel.com>`입니다.
Intel Xeon server의 uncore는 workload 특성에 따라 상당한 power를 소비할 수 있습니다. Total power를 최적화하고 전체 performance를 높이기 위해 SoC에는 uncore workload usage를 감시하고 바람직한 frequency를 설정하는 내부 uncore frequency scaling algorithm이 있습니다.
사용자는 uncore performance에 다른 기대를 가지고 직접 제어하려 할 수 있습니다. 이는 CPU performance 개선을 위해 cpufreq `sysfs`로 scaling minimum과 maximum frequency를 설정하는 목적과 비슷합니다. Latency-sensitive workload에서는 uncore frequency가 변하지 않기를 원할 수 있고, phase마다 core와 uncore performance 요구가 다른 workload에서는 cpufreq와 uncore scaling interface를 함께 사용해 power를 배분하고 전체 performance를 높일 수 있습니다.
기본 `sysfs` interface
29-61Uncore frequency 제어 interface는 `/sys/devices/system/cpu/intel_uncore_frequency/` directory에 있습니다.
여러 die를 가진 package에서는 uncore scaling control 범위가 die별이고, package마다 die가 하나인 SoC에서는 package별입니다. 따라서 package와 die 조합마다 directory가 하나 있으며 이름이 control scope를 나타냅니다. 예를 들어 `package_00_die_00`은 package ID 0, die 0을 뜻합니다.
`initial_max_freq_khz`는 reset 직후 가능한 maximum frequency를 나타내는 read-only attribute입니다. 사용자가 `max_freq_khz`를 조정한 뒤 이 값으로 원래 maximum에 돌아갈 수 있습니다.
`initial_min_freq_khz`는 reset 직후 가능한 minimum frequency를 나타내는 read-only attribute입니다. `min_freq_khz`를 조정한 뒤 이 값으로 원래 minimum에 돌아갈 수 있습니다.
`max_freq_khz`는 maximum uncore frequency를 설정하고, `min_freq_khz`는 minimum uncore frequency를 설정하며, `current_freq_khz`는 현재 uncore frequency를 읽습니다.
TPMI SoC와 fabric cluster
62-88TPMI는 Topology Aware Register and PM Capsule Interface입니다. SoC에는 개별 mesh partition 또는 여러 partition의 집합으로 이루어진 power domain이 여러 개 있을 수 있으며, 이 partition을 fabric cluster라 합니다.
같은 frequency로 실행해야 하는 특정 mesh type은 같은 fabric cluster에 배치됩니다. Fabric cluster는 partitioned fabric을 가진 SoC를 확장성 있게 다루는 mechanism을 제공합니다.
기존 `sysfs` interface는 package와 die 수준 control만 지원하므로 더 세밀한 fabric-cluster level control에는 충분하지 않습니다. TPMI 지원 SoC는 여러 power domain을 가질 수 있고 각 domain에는 하나 이상의 fabric cluster가 들어갑니다.
TPMI가 없는 system과 같은 package·die control에 더해 fabric cluster level control을 나타내도록 `sysfs`가 확장됩니다. 이 세밀한 interface는 `uncore00`, `uncore01`처럼 `uncore` prefix를 가진 directory로 제공됩니다. Directory 안의 `package_id`, `domain_id`, `fabric_cluster_id` attribute가 control scope를 지정합니다.
TPMI attribute와 control 전파
89-126`domain_id`는 instance의 power domain ID를, `fabric_cluster_id`는 fabric cluster ID를, `package_id`는 package ID를 읽습니다.
`die_id`는 instance의 Linux die ID를 읽습니다. 이 attribute는 core agent가 있는 domain에서 CPUID leaf `0x1f`가 die ID를 제공할 때만 존재합니다.
`agent_types`는 domain에 있는 모든 hardware agent를 표시합니다. 각 agent는 core, cache, memory, I/O를 포함한 하나 이상의 hardware subsystem을 제어할 수 있습니다. 다른 frequency attribute는 `package_*_die_*` 수준과 같습니다.
현재 대부분의 use case는 `package_*_die_*` 수준에서 `max_freq_khz`와 `min_freq_khz`를 갱신하며 이 model도 계속 지원합니다. 이 수준의 control을 사용하면 해당 package와 die의 모든 fabric cluster가 영향을 받습니다.
예를 들어 `package_00_die_00`의 `max_freq_khz`를 바꾸면 package ID가 같은 모든 `uncore*` directory의 `max_freq_khz`가 갱신됩니다. 그 뒤 각 `uncore*` 수준에서 더 restrictive한 maximum을 설정할 수 있습니다. `min_freq_khz`도 package·die 수준에서 모든 `uncore*`에 적용할 수 있습니다.
`current_freq_khz`는 각 fabric cluster 수준, 즉 `uncore*` directory에서만 지원됩니다.
Efficiency와 latency tradeoff
127-156ELC(Efficiency Latency Control)는 watt당 performance를 높이는 기능입니다. Hardware power-management algorithm이 latency와 power consumption의 tradeoff를 최적화하며, latency-sensitive workload에서는 software가 추가로 조정해 원하는 performance를 얻을 수 있습니다.
Hardware는 power domain의 모든 core에 대한 average CPU utilization을 일정 간격으로 감시해 uncore frequency를 결정합니다. 이 방식이 watt당 최상의 performance를 낼 수 있지만 workload는 power를 더 쓰더라도 높은 performance를 원할 수 있습니다. 예를 들어 대체로 idle인 system에서 application이 간헐적으로 깨어 memory read를 수행하면 hardware가 uncore frequency를 낮춘 뒤 target performance까지 다시 높이는 데 지연이 생길 수 있습니다.
ELC는 software에서 바꿀 수 있는 parameter를 제공합니다. Average CPU utilization이 user-defined `elc_low_threshold_percent`보다 낮으면 hardware가 계산한 minimum 대신 user-defined `elc_floor_freq_khz`를 uncore floor frequency로 사용합니다.
High-load 상황에서 CPU utilization이 `elc_high_threshold_percent`를 넘으면 maximum uncore frequency로 즉시 뛰지 않고 100 MHz step으로 올립니다. CPU utilization spike가 생기자마자 불필요하게 높은 power를 소비하는 일을 피합니다.
ELC attribute와 설정 예
157-184`elc_floor_freq_khz`는 efficiency-latency floor frequency를 읽고 설정합니다. 이 값이 `min_freq_khz`보다 낮으면 firmware가 무시합니다.
`elc_low_threshold_percent`는 ELC low threshold를 CPU utilization 백분율로 읽고 설정합니다. `elc_high_threshold_percent`는 high threshold를 같은 단위로 읽고 설정합니다.
`elc_high_threshold_enable`은 ELC high threshold를 활성화하거나 비활성화합니다. `1`을 쓰면 활성화하고 `0`을 쓰면 비활성화합니다.
다음 example은 CPU utilization이 10% 미만이면 uncore frequency를 800MHz로 설정하고, 95%보다 높으면 power limit에 도달할 때까지 100MHz step으로 높입니다.
elc_floor_freq_khz:800000
elc_high_threshold_percent:95
elc_high_threshold_enable:1
elc_low_threshold_percent:10
요약과 해설
intel_uncore_frequency_scaling.rst:1-184기본 interface는 package와 die 범위에 적용되고, TPMI interface는 같은 control을 fabric cluster까지 세분화합니다. 상위 범위의 변경은 하위 cluster 전체에 전파되지만 cluster별로 더 restrictive한 값을 다시 설정할 수 있습니다.
ELC는 low load에서 floor를 보장하고 high load에서 frequency를 단계적으로 높여 latency와 급격한 power 증가 사이를 조정합니다.