Lines Matching refs:CPU
18 1. CPU算力
24 一般来说，同构的SMP平台由完全相同的CPU构成。异构的平台则由性能特征不同的CPU构成，在这样的
25 平台中，CPU不能被认为是相同的。
27 我们引入CPU算力（capacity）的概念来测量每个CPU能达到的性能，它的值相对系统中性能最强的CPU
28 做过归一化处理。异构系统也被称为非对称CPU算力系统，因为它们由不同算力的CPU组成。
30 最大可达性能（换言之，最大CPU算力）的差异有两个主要来源:
32 - 不是所有CPU的微架构都相同。
33 - 在动态电压频率升降（Dynamic Voltage and Frequency Scaling，DVFS）框架中，不是所有的CPU都
39 CPU性能通常由每秒百万指令（Millions of Instructions Per Second，MIPS）表示，也可表示为
47 调度器使用了两种不同的算力值。CPU的 ``capacity_orig`` 是它的最大可达算力，即最大可达性能等级。
48 CPU的 ``capacity`` 是 ``capacity_orig`` 扣除了一些性能损失（比如处理中断的耗时）的值。
50 注意CPU的 ``capacity`` 仅仅被设计用于CFS调度类，而 ``capacity_orig`` 是不感知调度类的。为
59 考虑一个假想的双核非对称CPU算力系统，其中
63 - 所有CPU以相同的固定频率运行
90 具有不同算力值的CPU，通常来说最大操作性能值也不同。考虑上一小节提到的CPU（也就是说，
101 执行1.3.1节描述的工作负载，每个CPU按最大频率运行，结果为::
117 需要注意的是，使用单一值来表示CPU性能的差异是有些争议的。两个不同的微架构的相对性能差异应该
127 算力感知调度要求描述任务需求，描述方式要和CPU算力相关。每个调度类可以用不同的方式描述它。
140 一个需要考虑的议题是，工作负载的占空比受CPU正在运行的操作性能值直接影响。考虑以给定的频率F
143 CPU work ^
152 CPU work ^
166 2.3 CPU不变性
169 CPU算力与任务利用率具有类型的效应，在算力不同的CPU上执行完全相同的工作负载，将算出不同的
177 每个CPU按最大频率执行指定周期性工作负载，结果为::
194 任务利用率信号可按下面公式处理成CPU算力不变的::
198 其中 ``max_capacity`` 是系统中最高的CPU算力。对上面的例子运用该公式，可以算出CPU算力不变
204 频率和CPU算力不变性都需要被应用到任务利用率的计算中，以便求出真正的不变信号。
205 任务利用率的伪计算公式是同时具备CPU和频率不变性的，也就是说，对于指定任务p::
211 也就是说，任务利用率不变量假定任务在系统中最高算力CPU上以最高频率运行，以此描述任务的行为。
219 CFS调度类基于实体负载跟踪机制（Per-Entity Load Tracking, PELT）维护了少量CPU和任务信号，
228 3.1 CPU算力
231 当前，Linux无法凭自身算出CPU算力，因此必须要有把这个信息传递给Linux的方式。每个架构必须为此
234 arm、arm64和RISC-V架构直接把这个信息映射到arch_topology驱动的CPU scaling数据中（译注：参考
235 arch_topology.h的percpu变量cpu_scale），它是从capacity-dmips-mhz CPU binding中衍生计算
244 实现该函数要求计算出每个CPU当前以什么频率在运行。实现它的一种方式是利用硬件计数器（x86的
245 APERF/MPERF，arm64的AMU），它能按CPU当前频率动态可扩展地升降递增计数器的速率。另一种方式是
251 在构建调度域时，调度器将会发现系统是否表现为非对称CPU算力。如果是，那么：
255 完整包含某个CPU算力值的全部CPU。
256 - SD_ASYM_CPUCAPACITY标志将在所有包含非对称CPU的调度域中被设置。
258 sched_asym_cpucapacity静态键的设计意图是，保护为非对称CPU算力系统所准备的代码。不过要注意的
282 由于“这是”非对称CPU算力系统，sched_asym_cpucapacity静态键将使能。然而，CPU 0--1对应的
286 因此，“典型的”保护非对称CPU算力代码路径的代码模式是：
304 它通常被称为算力适应性准则。也就是说，CFS必须保证任务“适合”在某个CPU上运行。如果准则被违反，
305 任务将要更长地消耗该CPU，任务是CPU受限的（CPU-bound）。
311 5.1.2 被唤醒任务的CPU选择
314 CFS任务唤醒的CPU选择，遵循上面描述的算力适应性准则。在此之上，uclamp被用来限制任务利用率，
315 这令用户空间对CFS任务的CPU选择有更多的控制。也就是说，CFS被唤醒任务的CPU选择，搜索满足以下
316 条件的CPU::
320 通过使用uclamp，举例来说，用户空间可以允许忙等待循环（100%使用率）在任意CPU上运行，只要给
322 的CPU上运行，只要给它设置高的uclamp.min值。
326 CFS的被唤醒的任务的CPU选择，可被能耗感知调度（Energy Aware Scheduling，EAS）覆盖，在
332 被唤醒任务的CPU选择的一个病理性的例子是，任务几乎不睡眠，那么也几乎不发生唤醒。考虑::
340 CPU work ^
347 CPU work ^
358 则任务可能变为CPU受限的，也就是说 ``task_util(p) > capacity(task_cpu(p))`` ；CPU算力
359 调度准则被违反，将不会有任何唤醒事件来修复这个错误的CPU选择。
363 当发生负载均衡时，如果一个misfit任务可以被迁移到一个相较当前运行的CPU具有更高算力的CPU上，
369 5.2.1 被唤醒任务的CPU选择
372 实时任务唤醒时的CPU选择，搜索满足以下条件的CPU::
376 同时仍然允许接着使用常规的优先级限制。如果没有CPU能满足这个算力准则，那么将使用基于严格
377 优先级的调度，CPU算力将被忽略。
382 5.3.1 被唤醒任务的CPU选择
385 最后期限任务唤醒时的CPU选择，搜索满足以下条件的CPU::
389 同时仍然允许接着使用常规的带宽和截止期限限制。如果没有CPU能满足这个算力准则，那么任务依然
390 在当前CPU队列中。