요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
==========================================
Dynamic Thermal Power Management framework
==========================================
On the embedded world, the complexity of the SoC leads to an
increasing number of hotspots which need to be monitored and mitigated
as a whole in order to prevent the temperature to go above the
normative and legally stated 'skin temperature'.
Another aspect is to sustain the performance for a given power budget,
for example virtual reality where the user can feel dizziness if the
performance is capped while a big CPU is processing something else. Or
reduce the battery charging because the dissipated power is too high
compared with the power consumed by other devices.
The user space is the most adequate place to dynamically act on the
different devices by limiting their power given an application
profile: it has the knowledge of the platform.
The Dynamic Thermal Power Management (DTPM) is a technique acting on
the device power by limiting and/or balancing a power budget among
different devices.
The DTPM framework provides an unified interface to act on the
device power.
Overview
========
The DTPM framework relies on the powercap framework to create the
powercap entries in the sysfs directory and implement the backend
driver to do the connection with the power manageable device.
The DTPM is a tree representation describing the power constraints
shared between devices, not their physical positions.
The nodes of the tree are a virtual description aggregating the power
characteristics of the children nodes and their power limitations.
The leaves of the tree are the real power manageable devices.
For instance::
SoC
|
`-- pkg
|
|-- pd0 (cpu0-3)
|
`-- pd1 (cpu4-5)
The pkg power will be the sum of pd0 and pd1 power numbers::
SoC (400mW - 3100mW)
|
`-- pkg (400mW - 3100mW)
|
|-- pd0 (100mW - 700mW)
|
`-- pd1 (300mW - 2400mW)
When the nodes are inserted in the tree, their power characteristics are propagated to the parents::
SoC (600mW - 5900mW)
|
|-- pkg (400mW - 3100mW)
| |
| |-- pd0 (100mW - 700mW)
| |
| `-- pd1 (300mW - 2400mW)
|
`-- pd2 (200mW - 2800mW)
Each node have a weight on a 2^10 basis reflecting the percentage of power consumption along the siblings::
SoC (w=1024)
|
|-- pkg (w=538)
| |
| |-- pd0 (w=231)
| |
| `-- pd1 (w=794)
|
`-- pd2 (w=486)
Note the sum of weights at the same level are equal to 1024.
When a power limitation is applied to a node, then it is distributed along the children given their weights. For example, if we set a power limitation of 3200mW at the 'SoC' root node, the resulting tree will be::
SoC (w=1024) <--- power_limit = 3200mW
|
|-- pkg (w=538) --> power_limit = 1681mW
| |
| |-- pd0 (w=231) --> power_limit = 378mW
| |
| `-- pd1 (w=794) --> power_limit = 1303mW
|
`-- pd2 (w=486) --> power_limit = 1519mW
Flat description
----------------
A root node is created and it is the parent of all the nodes. This
description is the simplest one and it is supposed to give to user
space a flat representation of all the devices supporting the power
limitation without any power limitation distribution.
Hierarchical description
------------------------
The different devices supporting the power limitation are represented
hierarchically. There is one root node, all intermediate nodes are
grouping the child nodes which can be intermediate nodes also or real
devices.
The intermediate nodes aggregate the power information and allows to
set the power limit given the weight of the nodes.
User space API
==============
As stated in the overview, the DTPM framework is built on top of the
powercap framework. Thus the sysfs interface is the same, please refer
to the powercap documentation for further details.
* power_uw: Instantaneous power consumption. If the node is an
intermediate node, then the power consumption will be the sum of all
children power consumption.
* max_power_range_uw: The power range resulting of the maximum power
minus the minimum power.
* name: The name of the node. This is implementation dependent. Even
if it is not recommended for the user space, several nodes can have
the same name.
* constraint_X_name: The name of the constraint.
* constraint_X_max_power_uw: The maximum power limit to be applicable
to the node.
* constraint_X_power_limit_uw: The power limit to be applied to the
node. If the value contained in constraint_X_max_power_uw is set,
the constraint will be removed.
* constraint_X_time_window_us: The meaning of this file will depend
on the constraint number.
Constraints
-----------
* Constraint 0: The power limitation is immediately applied, without
limitation in time.
Kernel API
==========
Overview
--------
The DTPM framework has no power limiting backend support. It is
generic and provides a set of API to let the different drivers to
implement the backend part for the power limitation and create the
power constraints tree.
It is up to the platform to provide the initialization function to
allocate and link the different nodes of the tree.
A special macro has the role of declaring a node and the corresponding
initialization function via a description structure. This one contains
an optional parent field allowing to hook different devices to an
already existing tree at boot time.
For instance::
struct dtpm_descr my_descr = {
.name = "my_name",
.init = my_init_func,
};
DTPM_DECLARE(my_descr);
The nodes of the DTPM tree are described with dtpm structure. The
steps to add a new power limitable device is done in three steps:
* Allocate the dtpm node
* Set the power number of the dtpm node
* Register the dtpm node
The registration of the dtpm node is done with the powercap
ops. Basically, it must implements the callbacks to get and set the
power and the limit.
Alternatively, if the node to be inserted is an intermediate one, then
a simple function to insert it as a future parent is available.
If a device has its power characteristics changing, then the tree must
be updated with the new power numbers and weights.
Nomenclature
------------
* dtpm_alloc() : Allocate and initialize a dtpm structure
* dtpm_register() : Add the dtpm node to the tree
* dtpm_unregister() : Remove the dtpm node from the tree
* dtpm_update_power() : Update the power characteristics of the dtpm node
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
DTPM의 목적
1-28SPDX license identifier는 `GPL-2.0`입니다.
Embedded 환경에서는 SoC가 복잡해질수록 hotspot 수가 늘어납니다. 규정과 법률에 명시된 `skin temperature`를 넘지 않으려면 이 hotspot들을 전체적으로 monitoring하고 완화해야 합니다.
또 다른 목표는 정해진 power budget 안에서 performance를 유지하는 것입니다. 예를 들어 virtual reality에서 큰 CPU가 다른 작업을 처리하는 동안 performance가 제한되면 사용자가 어지럼증을 느낄 수 있습니다. 또는 다른 장치가 소비하는 power에 비해 방출 power가 너무 크면 battery charging을 줄여야 할 수 있습니다.
Application profile과 platform 정보를 알고 있는 사용자 공간이 각 장치의 power를 제한해 동적으로 조정하기에 가장 적합합니다.
Dynamic Thermal Power Management(DTPM)는 여러 장치 사이에서 power budget을 제한하거나 균형 있게 배분해 장치 power에 작용하는 기법입니다. DTPM framework는 장치 power를 제어하는 통합 인터페이스를 제공합니다.
사용자 공간의 platform 지식이 device별 power 제한과 전체 thermal 목표를 연결합니다.
.. SPDX-License-Identifier: GPL-2.0
==========================================
Dynamic Thermal Power Management framework
==========================================
On the embedded world, the complexity of the SoC leads to an
increasing number of hotspots which need to be monitored and mitigated
as a whole in order to prevent the temperature to go above the
normative and legally stated 'skin temperature'.
Another aspect is to sustain the performance for a given power budget,
for example virtual reality where the user can feel dizziness if the
performance is capped while a big CPU is processing something else. Or
reduce the battery charging because the dissipated power is too high
compared with the power consumed by other devices.
The user space is the most adequate place to dynamically act on the
different devices by limiting their power given an application
profile: it has the knowledge of the platform.
The Dynamic Thermal Power Management (DTPM) is a technique acting on
the device power by limiting and/or balancing a power budget among
different devices.
The DTPM framework provides an unified interface to act on the
device power.
Powercap 기반의 논리적 power tree
29-43DTPM framework는 powercap framework를 사용해 sysfs directory에 powercap entry를 만들고, backend driver를 구현해 power를 관리할 수 있는 device와 연결합니다.
DTPM tree는 device의 물리적 위치가 아니라 device 사이에 공유되는 power constraint를 표현합니다.
Tree node는 child node의 power 특성과 power limitation을 집계하는 가상 표현이며, leaf는 실제로 power를 관리할 수 있는 device입니다.
Intermediate node는 집계와 분배를 담당하고 leaf는 실제 device를 제어합니다.
Overview
========
The DTPM framework relies on the powercap framework to create the
powercap entries in the sysfs directory and implement the backend
driver to do the connection with the power manageable device.
The DTPM is a tree representation describing the power constraints
shared between devices, not their physical positions.
The nodes of the tree are a virtual description aggregating the power
characteristics of the children nodes and their power limitations.
The leaves of the tree are the real power manageable devices.
기본 SoC tree와 power 합산
44-63예시 tree에서 `SoC` 아래의 `pkg`는 `pd0(cpu0-3)`과 `pd1(cpu4-5)`를 child로 갖습니다.
`pkg` power 범위는 `pd0`과 `pd1`의 power 수치를 합한 값입니다. `pd0`가 100~700mW이고 `pd1`이 300~2400mW이므로 `pkg`와 그 하나뿐인 parent `SoC`는 400~3100mW가 됩니다.
원문의 첫 ASCII tree를 parent-child 표로 재구성했습니다.
Intermediate node의 최소·최대 power는 child 범위의 합입니다.
For instance::
SoC
|
`-- pkg
|
|-- pd0 (cpu0-3)
|
`-- pd1 (cpu4-5)
The pkg power will be the sum of pd0 and pd1 power numbers::
SoC (400mW - 3100mW)
|
`-- pkg (400mW - 3100mW)
|
|-- pd0 (100mW - 700mW)
|
`-- pd1 (300mW - 2400mW)
Node 삽입과 parent 전파
64-75Node를 tree에 삽입하면 그 power 특성이 parent로 전파됩니다. 예시에서 `SoC`는 기존 `pkg` 400~3100mW에 새 child `pd2` 200~2800mW를 더해 600~5900mW가 됩니다. `pkg` 아래의 `pd0`과 `pd1` 범위는 그대로입니다.
새 leaf의 범위가 intermediate node를 거쳐 root 집계값에 반영됩니다.
When the nodes are inserted in the tree, their power characteristics are propagated to the parents::
SoC (600mW - 5900mW)
|
|-- pkg (400mW - 3100mW)
| |
| |-- pd0 (100mW - 700mW)
| |
| `-- pd1 (300mW - 2400mW)
|
`-- pd2 (200mW - 2800mW)
2^10 기반 sibling weight
76-89각 node에는 sibling 사이의 power consumption 비율을 나타내는 `2^10`, 즉 1024 기반 weight가 있습니다. 같은 level에 있는 sibling의 weight 합은 1024입니다.
Root `SoC`의 weight는 1024입니다. 그 아래 `pkg`는 538, `pd2`는 486으로 합이 1024입니다. `pkg` 아래에서는 `pd0`가 231, `pd1`이 794이며 역시 합이 1024입니다.
Weight는 각 sibling level 안에서 독립적으로 정규화됩니다.
Each node have a weight on a 2^10 basis reflecting the percentage of power consumption along the siblings::
SoC (w=1024)
|
|-- pkg (w=538)
| |
| |-- pd0 (w=231)
| |
| `-- pd1 (w=794)
|
`-- pd2 (w=486)
Note the sum of weights at the same level are equal to 1024.
Power limit의 가중 분배
90-102어떤 node에 power limitation을 적용하면 child의 weight에 따라 제한을 분배합니다. `SoC` root에 3200mW 제한을 설정한 예에서는 `pkg`에 1681mW, `pd2`에 1519mW가 배정됩니다.
`pkg`의 1681mW는 다시 child weight에 따라 `pd0` 378mW와 `pd1` 1303mW로 분배됩니다.
각 단계에서 sibling weight 비율로 parent budget을 나눕니다.
Root 제한은 intermediate node를 거쳐 실제 leaf device까지 내려갑니다.
When a power limitation is applied to a node, then it is distributed along the children given their weights. For example, if we set a power limitation of 3200mW at the 'SoC' root node, the resulting tree will be::
SoC (w=1024) <--- power_limit = 3200mW
|
|-- pkg (w=538) --> power_limit = 1681mW
| |
| |-- pd0 (w=231) --> power_limit = 378mW
| |
| `-- pd1 (w=794) --> power_limit = 1303mW
|
`-- pd2 (w=486) --> power_limit = 1519mW
Flat description과 hierarchical description
103-121Flat description은 root node 하나를 만들고 모든 node를 그 direct child로 둡니다. Power limitation 분배 없이 제한을 지원하는 모든 device를 사용자 공간에 평평하게 보여 주는 가장 단순한 표현입니다.
Hierarchical description은 power limitation을 지원하는 device를 계층적으로 표현합니다. Root는 하나이며 intermediate node는 다른 intermediate node 또는 실제 device인 child를 묶습니다.
Intermediate node는 power 정보를 집계하고 node weight에 따라 power limit을 설정할 수 있게 합니다.
정책에 필요한 집계와 분배 여부에 따라 tree 구조를 선택합니다.
Flat description
----------------
A root node is created and it is the parent of all the nodes. This
description is the simplest one and it is supposed to give to user
space a flat representation of all the devices supporting the power
limitation without any power limitation distribution.
Hierarchical description
------------------------
The different devices supporting the power limitation are represented
hierarchically. There is one root node, all intermediate nodes are
grouping the child nodes which can be intermediate nodes also or real
devices.
The intermediate nodes aggregate the power information and allows to
set the power limit given the weight of the nodes.
DTPM 사용자 공간 API
122-151DTPM은 powercap framework 위에 구축되므로 같은 sysfs interface를 사용합니다. 자세한 형식은 powercap 문서를 참고합니다.
`power_uw`는 instantaneous power consumption입니다. Intermediate node에서는 모든 child power consumption의 합입니다. `max_power_range_uw`는 maximum power에서 minimum power를 뺀 power range입니다.
`name`은 구현에 따라 정해지는 node 이름입니다. 사용자 공간에 권장되지는 않지만 여러 node가 같은 이름을 가질 수 있습니다.
`constraint_X_name`은 constraint 이름이고 `constraint_X_max_power_uw`는 node에 적용할 수 있는 maximum power limit입니다.
`constraint_X_power_limit_uw`는 node에 적용할 power limit입니다. `constraint_X_max_power_uw`에 들어 있는 값을 설정하면 constraint가 제거됩니다. `constraint_X_time_window_us`의 의미는 constraint number에 따라 달라집니다.
Intermediate node의 power는 child 합계로 계산됩니다.
User space API
==============
As stated in the overview, the DTPM framework is built on top of the
powercap framework. Thus the sysfs interface is the same, please refer
to the powercap documentation for further details.
* power_uw: Instantaneous power consumption. If the node is an
intermediate node, then the power consumption will be the sum of all
children power consumption.
* max_power_range_uw: The power range resulting of the maximum power
minus the minimum power.
* name: The name of the node. This is implementation dependent. Even
if it is not recommended for the user space, several nodes can have
the same name.
* constraint_X_name: The name of the constraint.
* constraint_X_max_power_uw: The maximum power limit to be applicable
to the node.
* constraint_X_power_limit_uw: The power limit to be applied to the
node. If the value contained in constraint_X_max_power_uw is set,
the constraint will be removed.
* constraint_X_time_window_us: The meaning of this file will depend
on the constraint number.
Constraint 0
152-157`Constraint 0`의 power limitation은 시간 제한 없이 즉시 적용됩니다.
현재 문서가 정의하는 첫 constraint의 시간 의미입니다.
Constraints
-----------
* Constraint 0: The power limitation is immediately applied, without
limitation in time.
Kernel API와 backend 책임
158-176DTPM framework 자체에는 power limiting backend 지원이 없습니다. Framework는 generic API를 제공하고, 각 driver가 power limitation backend와 power constraint tree 생성을 구현합니다.
Tree node를 allocate하고 서로 연결하는 initialization function은 platform이 제공해야 합니다.
특별한 macro는 description structure를 통해 node와 대응 initialization function을 선언합니다. Description에는 optional parent field가 있어 boot 때 이미 존재하는 tree에 다른 device를 연결할 수 있습니다.
Generic tree 관리와 실제 power 제어 backend를 분리합니다.
Kernel API
==========
Overview
--------
The DTPM framework has no power limiting backend support. It is
generic and provides a set of API to let the different drivers to
implement the backend part for the power limitation and create the
power constraints tree.
It is up to the platform to provide the initialization function to
allocate and link the different nodes of the tree.
A special macro has the role of declaring a node and the corresponding
initialization function via a description structure. This one contains
an optional parent field allowing to hook different devices to an
already existing tree at boot time.
Node 선언과 등록 절차
177-202예제는 `struct dtpm_descr my_descr`에 `.name = "my_name"`과 `.init = my_init_func`를 설정하고 `DTPM_DECLARE(my_descr)`로 선언합니다.
DTPM tree node는 `dtpm` structure로 표현합니다. 새 power-limitable device를 추가하는 절차는 dtpm node allocate, node의 power number 설정, node 등록의 세 단계입니다.
Dtpm node 등록은 powercap ops로 수행하며, 기본적으로 power와 limit을 읽고 쓰는 callback을 구현해야 합니다.
삽입할 node가 intermediate node라면 future parent로 넣는 간단한 함수도 사용할 수 있습니다.
Device의 power characteristic이 바뀌면 새 power number와 weight로 tree를 갱신해야 합니다.
Description 선언부터 backend callback과 동적 갱신까지의 순서입니다.
For instance::
struct dtpm_descr my_descr = {
.name = "my_name",
.init = my_init_func,
};
DTPM_DECLARE(my_descr);
The nodes of the DTPM tree are described with dtpm structure. The
steps to add a new power limitable device is done in three steps:
* Allocate the dtpm node
* Set the power number of the dtpm node
* Register the dtpm node
The registration of the dtpm node is done with the powercap
ops. Basically, it must implements the callbacks to get and set the
power and the limit.
Alternatively, if the node to be inserted is an intermediate one, then
a simple function to insert it as a future parent is available.
If a device has its power characteristics changing, then the tree must
be updated with the new power numbers and weights.
DTPM 함수 명칭
203-212`dtpm_alloc()`은 `dtpm` structure를 allocate하고 initialize합니다. `dtpm_register()`는 dtpm node를 tree에 추가하고 `dtpm_unregister()`는 tree에서 제거합니다. `dtpm_update_power()`는 dtpm node의 power characteristic을 갱신합니다.
Node 수명과 동적 power 정보 갱신을 담당합니다.
Nomenclature
------------
* dtpm_alloc() : Allocate and initialize a dtpm structure
* dtpm_register() : Add the dtpm node to the tree
* dtpm_unregister() : Remove the dtpm node from the tree
* dtpm_update_power() : Update the power characteristics of the dtpm node
요약·해설
dtpm.rst:1-212DTPM은 물리적 배치가 아니라 power constraint 공유 관계를 tree로 표현합니다. Intermediate node가 child의 범위와 power를 합산하고 1024 기반 weight로 parent limit을 leaf device까지 분배하며, 실제 제어는 platform backend가 구현합니다.