~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/translations/zh_CN/power/energy-model.rst

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

  1 .. SPDX-License-Identifier: GPL-2.0
  2 .. include:: ../disclaimer-zh_CN.rst
  3 
  4 :Original: Documentation/power/energy-model.rst
  5 
  6 :翻译:
  7 
  8   唐艺舟 Tang Yizhou <tangyeechou@gmail.com>
  9 
 10 ============
 11 设备能量模型
 12 ============
 13 
 14 1. 概述
 15 -------
 16 
 17 能量模型(EM)框架是一种驱动程序与内核子系统之间的接口。其中驱动程序了解不同
 18 性能层级的设备所消耗的功率,而内核子系统愿意使用该信息做出能量感知决策。
 19 
 20 设备所消耗的功率的信息来源在不同的平台上可能有很大的不同。这些功率成本在某些
 21 情况下可以使用设备树数据来估算。在其它情况下,固件会更清楚。或者,用户空间可能
 22 是最清楚的。以此类推。为了避免每一个客户端子系统对每一种可能的信息源自己重新
 23 实现支持,EM框架作为一个抽象层介入,它在内核中对功率成本表的格式进行标准化,
 24 因此能够避免多余的工作。
 25 
 26 功率值可以用微瓦或“抽象刻度”表示。多个子系统可能使用EM,由系统集成商来检查
 27 功率值刻度类型的要求是否满足。可以在能量感知调度器的文档中找到一个例子
 28 Documentation/scheduler/sched-energy.rst。对于一些子系统,比如热能或
 29 powercap,用“抽象刻度”描述功率值可能会导致问题。这些子系统对过去使用的功率的
 30 估算值更感兴趣,因此可能需要真实的微瓦。这些要求的一个例子可以在智能功率分配
 31 Documentation/driver-api/thermal/power_allocator.rst文档中找到。
 32 
 33 内核子系统可能(基于EM内部标志位)实现了对EM注册设备是否具有不一致刻度的自动
 34 检查。要记住的重要事情是,当功率值以“抽象刻度”表示时,从中推导以微焦耳为单位
 35 的真实能量消耗是不可能的。
 36 
 37 下图描述了一个驱动的例子(这里是针对Arm的,但该方法适用于任何体系结构),它
 38 向EM框架提供了功率成本,感兴趣的客户端可从中读取数据::
 39 
 40        +---------------+  +-----------------+  +---------------+
 41        | Thermal (IPA) |  | Scheduler (EAS) |  |     Other     |
 42        +---------------+  +-----------------+  +---------------+
 43                |                   | em_cpu_energy()   |
 44                |                   | em_cpu_get()      |
 45                +---------+         |         +---------+
 46                          |         |         |
 47                          v         v         v
 48                         +---------------------+
 49                         |    Energy Model     |
 50                         |     Framework       |
 51                         +---------------------+
 52                            ^       ^       ^
 53                            |       |       | em_dev_register_perf_domain()
 54                 +----------+       |       +---------+
 55                 |                  |                 |
 56         +---------------+  +---------------+  +--------------+
 57         |  cpufreq-dt   |  |   arm_scmi    |  |    Other     |
 58         +---------------+  +---------------+  +--------------+
 59                 ^                  ^                 ^
 60                 |                  |                 |
 61         +--------------+   +---------------+  +--------------+
 62         | Device Tree  |   |   Firmware    |  |      ?       |
 63         +--------------+   +---------------+  +--------------+
 64 
 65 对于CPU设备,EM框架管理着系统中每个“性能域”的功率成本表。一个性能域是一组
 66 性能一起伸缩的CPU。性能域通常与CPUFreq策略具有1对1映射。一个性能域中的
 67 所有CPU要求具有相同的微架构。不同性能域中的CPU可以有不同的微架构。
 68 
 69 
 70 2. 核心API
 71 ----------
 72 
 73 2.1 配置选项
 74 ^^^^^^^^^^^^
 75 
 76 必须使能CONFIG_ENERGY_MODEL才能使用EM框架。
 77 
 78 
 79 2.2 性能域的注册
 80 ^^^^^^^^^^^^^^^^
 81 
 82 “高级”EM的注册
 83 ~~~~~~~~~~~~~~~~
 84 
 85 “高级”EM因它允许驱动提供更精确的功率模型而得名。它并不受限于框架中的一些已
 86 实现的数学公式(就像“简单”EM那样)。它可以更好地反映每个性能状态的实际功率
 87 测量。因此,在EM静态功率(漏电流功率)是重要的情况下,应该首选这种注册方式。
 88 
 89 驱动程序应通过以下API将性能域注册到EM框架中::
 90 
 91   int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
 92                 struct em_data_callback *cb, cpumask_t *cpus, bool microwatts);
 93 
 94 驱动程序必须提供一个回调函数,为每个性能状态返回<频率,功率>元组。驱动程序
 95 提供的回调函数可以自由地从任何相关位置(DT、固件......)以及以任何被认为是
 96 必要的方式获取数据。只有对于CPU设备,驱动程序必须使用cpumask指定性能域的CPU。
 97 对于CPU以外的其他设备,最后一个参数必须被设置为NULL。
 98 
 99 最后一个参数“microwatts”(微瓦)设置成正确的值是很重要的,使用EM的内核
100 子系统可能会依赖这个标志来检查所有的EM设备是否使用相同的刻度。如果有不同的
101 刻度,这些子系统可能决定返回警告/错误,停止工作或崩溃(panic)。
102 
103 关于实现这个回调函数的驱动程序的例子,参见第3节。或者在第2.4节阅读这个API
104 的更多文档。
105 
106 使用DT的EM注册
107 ==============
108 
109 EM也可以使用OPP框架和DT "操作点-v2 "中的信息注册。DT中的每个OPP条目都可
110 以用一个包含微瓦特功率值的属性 "op-microwatt "来扩展。这个OPP DT属性允
111 许平台注册反映总功率(静态+动态)的EM功率值。这些功率值可能直接来自实验和
112 测量。
113 
114 “人工”EM的注册
115 ==============
116 
117 有一个选项可以为缺少关于每个性能状态的功率值的详细知识的驱动程序提供一个自
118 定义回调。回调.get_cost()是可选的,它提供EAS使用的“成本”值。这对那些只提
119 供CPU类型之间相对效率信息的平台很有用,人们可以利用这些信息来创建一个抽象的
120 功率模型。但是,考虑到输入功率值的大小限制,即使是抽象的功率模型有时也很难装
121 进去。.get_cost()允许提供反映CPU效率的“成本”值。这将允许提供EAS信息,它
122 与EM内部计算'成本'值的公式有不同的关系。要为这样的平台注册EM,驱动程序必须
123 将标志“microwatts”设置为0,提供.get_power()回调和.get_cost()回调。EM
124 框架会在注册过程中正确处理这样的平台。这种平台会被设置EM_PERF_DOMAIN_ARTIFICIAL
125 标志。其他使用EM的框架应该特别注意测试和正确对待这个标志。
126 
127 “简单”EM的注册
128 ~~~~~~~~~~~~~~~~
129 
130 “简单”EM是用框架的辅助函数cpufreq_register_em_with_opp()注册的。它实现了
131 一个和以下数学公式紧密相关的功率模型::
132 
133         Power = C * V^2 * f
134 
135 使用这种方法注册的EM可能无法正确反映真实设备的物理特性,例如当静态功率
136 (漏电流功率)很重要时。
137 
138 
139 2.3 访问性能域
140 ^^^^^^^^^^^^^^
141 
142 有两个API函数提供对能量模型的访问。em_cpu_get()以CPU id为参数,em_pd_get()
143 以设备指针为参数。使用哪个接口取决于子系统,但对于CPU设备来说,这两个函数都返
144 回相同的性能域。
145 
146 对CPU的能量模型感兴趣的子系统可以通过em_cpu_get() API检索它。在创建性能域时
147 分配一次能量模型表,它保存在内存中不被修改。
148 
149 一个性能域所消耗的能量可以使用em_cpu_energy() API来估算。该估算假定CPU设备
150 使用的CPUfreq监管器是schedutil。当前该计算不能提供给其它类型的设备。
151 
152 关于上述API的更多细节可以在 ``<linux/energy_model.h>`` 或第2.4节中找到。
153 
154 
155 2.4 API的细节描述
156 ^^^^^^^^^^^^^^^^^
157 参见 include/linux/energy_model.h 和 kernel/power/energy_model.c 的kernel doc。
158 
159 3. 驱动示例
160 -----------
161 
162 CPUFreq框架支持专用的回调函数,用于为指定的CPU(们)注册EM:
163 cpufreq_driver::register_em()。这个回调必须为每个特定的驱动程序正确实现,
164 因为框架会在设置过程中适时地调用它。本节提供了一个简单的例子,展示CPUFreq驱动
165 在能量模型框架中使用(假的)“foo”协议注册性能域。该驱动实现了一个est_power()
166 函数提供给EM框架::
167 
168   -> drivers/cpufreq/foo_cpufreq.c
169 
170   01   static int est_power(struct device *dev, unsigned long *mW,
171   02                   unsigned long *KHz)
172   03    {
173   04            long freq, power;
174   05
175   06            /* 使用“foo”协议设置频率上限 */
176   07            freq = foo_get_freq_ceil(dev, *KHz);
177   08            if (freq < 0);
178   09                    return freq;
179   10
180   11            /* 估算相关频率下设备的功率成本 */
181   12            power = foo_estimate_power(dev, freq);
182   13            if (power < 0);
183   14                    return power;
184   15
185   16            /* 将这些值返回给EM框架 */
186   17            *mW = power;
187   18            *KHz = freq;
188   19
189   20            return 0;
190   21    }
191   22
192   23    static void foo_cpufreq_register_em(struct cpufreq_policy *policy)
193   24    {
194   25            struct em_data_callback em_cb = EM_DATA_CB(est_power);
195   26            struct device *cpu_dev;
196   27            int nr_opp;
197   28
198   29            cpu_dev = get_cpu_device(cpumask_first(policy->cpus));
199   30
200   31            /* 查找该策略支持的OPP数量 */
201   32            nr_opp = foo_get_nr_opp(policy);
202   33
203   34            /* 并注册新的性能域 */
204   35            em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus,
205   36                                        true);
206   37    }
207   38
208   39    static struct cpufreq_driver foo_cpufreq_driver = {
209   40            .register_em = foo_cpufreq_register_em,
210   41    };

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php